[Building Sakai] Portal NEO Prefix

[Charles Severance]

On Mar 19, 2013, at 12:02 AM, Steve Swinsburg wrote:

> The issue here is the automatic prefixing of the skin names by the portal. This is not necessary for sites to choose their own skin if the skin is compatible with the set of portal templates that they are using. It *is* confusing, made evident by this thread.

I need a more tangible example.  If we have two templates and they have different skin requirements perhaps even to the level of how tool.css interacts with portal.css, then it would seem list we need parallel sets of each custom skin.  And the prefix allows this.

If I look in reference I see:

./skin/default/tool.css
./skin/default-horiz/tool.css
./skin/examp-u/tool.css

./skin/neo-default/tool.css
./skin/neo-default-horiz/tool.css
./skin/neo-examp-u/tool.css

It is 100% parallel.  Now you might argue that we should have used a folder structure.  That is cosmetic and would not remove the need to pre-pend something - it would have been a slash instead of a dash.

So give me a counter proposal that still allows 100% parallel tool.css and portal.css but somehow has no "prefix" or something other way to switch between sets of skins.  And remember the site properties that put these strings in before any notion of switching skin sets was created.  I would really like a proposal that does not require database upgrade scripts to be run when skins are changed - which is how I designed the above - to be conversion free and allowing a site to roll forward and back with nothing more and a prop change.

Also remember that files like default/tool.css are sitting in tons of vendor branches and I wanted not to move the old skin files just for the sake of prettiness and cause a bunch of angst in vendors branches.

I am sure our documentation can be improved and perhaps a folder structure for new skins rather than a file naming convention might feel more elegant.

I thin that the primary source of confusion is that for nearly a decade *nothing changed* in this folder - and in 2.9 we introduced parallel skin / template sets - and perhaps with less than sufficient announcements / documentation / transition guides.   That causes an instant "who moved my cheese" reaction of course.  But at this point unless I am completely missing something, adding something like a different folder structure (which does not eliminate the prefix) just to make it a little more elegant probably does not meet a cost/benefit analysis now that we have figured it out and are nicely fixing the tools (I thank you for that and the Wicket developers that want to use the rich editor thank you for that and Noah thanks you for that since now he does not have to fix the Wicket tools:) ).  

I was thinking I should update that 2005 document to point out how to handle onload dat from the portal if the tool is living large with JQuery.  We should be clear that what is there is JavaScript suitable for onload or similar moment when page loading has been completed.  I should further say in that document that document ready is *preferred* over onload as it will give tools the best chance of getting frame height right.

/Chuck

P.S. I am bumming that the detail regarding these design choices is only getting good discussion a year after 2.9 came out :)  A lot of thought went into the choices but as we were all sprinting in our little corners trying to get 2.9.0 out the door - it was me and Gonzalo flipping coins on this one.  Whatever is bad on this design (if any) is almost certainly my fault :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130319/0da6f069/attachment.html