[Building Sakai] Portal NEO Prefix

[Charles Severance]

On Mar 17, 2013, at 10:05 AM, David Adams wrote:

> I understand there may be some reason why sites with custom skins need
> this treatment, but there's no reason that should affect what the value
> of "skin.default" means.


Dave,

This is good - we are narrowing the discussion and not debating in areas where we agree - whew.  I have snipped out the agreement parts above.

As you say below, it comes down to custom skins that are per-site and how we made / make the decision on a naming convention for these skins.

In 2.8 when a site had custom skins and a skin picker, they might have a skins named default, med, law, and eng and have a CSS for each one.   Once there is a custom skin it becomes a site property and over the years we accumulated a lot of sites with this property set.

When we were imagining 2.9 and the neo variant, we had a decision to make.   We had several choices.   We could have hoped that the same custom tool skin could be used for neo and non-neo.   I was afraid this would not work.   I was not sure it would not work - I just felt it was safer to have a way to have each prefix to have independent custom skins.

default, med, law, and eng

*and*

neo-default, neo-med, neo-law, and neo-eng

And have these available at the same time and to be able to instantly switch back and forth with merely a prefix property and not to have to have a set of patches to the non-prefixed skins that had to be applied / removed each time a template switch happened.  I wanted the skin files to stay unchanged in the case of a prefix switch.   I wanted schools to be able to 100% freeze the old skins and build new skins in a new place and fully test and then if things went badly switch back without de-applying the changes.

Also I did not want a conversion process that would go through site properties and switch "eng" to "neo-eng" in the site properties.   In particular because I wanted to give schools the option to switch between their set of custom skins with only a property change.  I also wanted to give the 2.9 release team the option to switch back quite close to release if it turned out that the neo skin was not ready for shipping.  I did not want to be patching the old files and then if something went wrong go scrambling to figure out how far back to revert the skins.   It also made QA for the 2.9 portal a lot easier because we were testing one portal or the other portal without any common material between them.  We could fix one without requiring a full re-QA of the other.

Also after 2.9 was released, if there were essential patches to the old skins or templates in case of a security bug - I wanted to make it really clear which changes to the skins were needed to cosmetically align with the new templates and which changes needed back-porting to 2.7 and 2.8.  Freezing and keeping the old skins - allowed us to do this.  We have a responsibility to keep old versions of or product up-to-date with essential and security fixes.   And I wanted to keep all the old files in exactly the same place so that those with vendor branches did not end up with a painful upgrade path.  When we switch for the neo- skin / templates to the hyper- skin / templates I want to also not break those vendor branches that have patched the neo- files.

By leaving the within-site properties as "eng" and not changing them to "neo-eng" - since we never converted the properties, we never have to unconvert them back if we want to back out - and if we want a new prefix like "mega-" we don't have to tweak the properties yet again.  The prefix was to be like a name space  - not just a new set of file names - and it was to create a 100% sealed isolation zone that allowed the prefix to be changed and the entire rest of the system to simply react.  I want the system to have more than one skin / template set available at the same time - we are not evolving a single skin - we have multiple skin / template sets that can independently evolve.

I want to be able to go back and forth between different prefixes in the portal without Site database conversions or a ton of skin patches that need to be tracked and untracked.  A *lot* of thought went into the approach that was taken - and it was done with the assumption that tools followed the proper conventions in generating their head material.

Honestly as I thought more about it over the past two days struggling to keep the prefix pure and clean and functioning like a namespace and keeping the flexibiltiy that we now have in the portal code, I have come to the conclusion that if tools refuse to take head material from the portal - then we might as well let them add code like:

https://jira.sakaiproject.org/secure/attachment/35410/STAT-345.patch

If they refuse to follow the convention then they *should* slowly replicate portal functionality if we change how the portal works.   They will have to go through this again if they want to properly use the rich text editor.  And in a future release we may change how we do the rich text editor or skins or JavaScript and we will have to go fix these "portal outposts" again.  I feel sorry for Noah when SiteStats wants to use the rich text editor and they ask him to re-implement all of the functionality now in portal in sitestats/../wicket/..BasePage.java.

I agree with Steve that we should avoid putting a bunch of clever / dynamic / active code into our properties code and slowly turn getString() into an API call - we want these calls to give the same thing all the time.

Tools (since 1.0) have always had a non-brittle way to do this - it does not require API changes and it works seamlessly and unchanged since 1.0 - velocity tools simply roll forward and backwards when the portal changes head material.  If Wicket tools don't want to take advantage of  the abstraction - it is on them to keep up and that means (for today) learning about the prefix as namespace.

Sorry for sticking to my guns on this.  I am kind of on a "reduce technical debt" kick - and when I see technical debt and the community response is "we like that particular technical debt because it is my code we wrote a long time ago we don't want to fix that technical debt in our code but instead I would prefer we want to add technical debt and break the architecture of  someone else's code so I can continue do things the wrong way in my own code"  - it does not tend to get me to back down and agree to a portal hack that clearly violates the design of multi-skin / multi-template support.

/Chuck

P.S. If the skin picker is putting "neo-med" in the Site properties instead of "med" when the user picks "Medicine" - then it is wrong too.   If it is doing it wrong since 2.9 - then I missed that one.  Grrr.  (Growling at myself) :(


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130317/434e32ee/attachment.html