[Building Sakai] Portal NEO Prefix

[Charles Severance]

Steve - Lets break this down to simpler decisions.  

I think that what you are advocating for is that a skin is a skin and we just accumulate them with whatever naming convention that we like and have no way of knowing or marking which skin works with which template set - but a clever admin will tweak things and tweak properties here and there remembering which skin they made for which purpose and it will all work.   Have the portal not doing any prefixing or skin grouping at all and let the admins keep track of it all, tweaking properties with SQL if they want and fully controlling their skin evolution.

I am advocating for the notion of switchable skin sets where we can have a complete and parallel sets of skins that are marked by some kind of directory convention or prefix naming convention.

What you should have done (and I should have documented) is that at the moment that you went from 2.8 to 2.9 was make a full copy of all your skins with exactly the same name with the neo-prefix and leave your pre-2.9 skins untouched.  Then work on all new skins with a neo-prefix and don't put the neo prefix in the site properties.

So lets focus on the simple question of whether or not you think skin sets are a good or bad idea.  

To help motivate your thinking, lets assume that in 2.9+ we have four sets of templates: (1) the old 2.8 templates, (2) the neo templates, (3) the xslt templates that allow us to provide the functionality of the xslt portal without using it so we avoid many different compatibility issues where we need to fix the regular portal and then later re-find the bug and re-fix the xslt portal - but the xslt portal has more flexibility so we are stuck - the new xslt templates solve this nicely, and (4) a pinterest-style portal where everything is an infinitely scrollable set of rectangles that you can swipe left or right, up or down and/or zoom in and out.  And lets further assume that completely different teams are developing the xslt and pinterest portals and we will only make a decision as to which will be the default after testing them all and before cutting the 2.9+ b01 tag.

If you recall, the switchable templates + switchable skins allows both the 2.8 and neo skins and templates to *co-exist* in trunk for yearly two years and allowed for really straighforward QA of both options without shuttling skin files in an out or having a future 2.9+ situation where the pinterest team mistakenly overwrote the skins for the neo portal because everything is in the same folder with no naming conventions.

I see the portal and its ability to build and evolve new skins without breaking old skins as a critical feature going forward.   As the functionality of these systems starts to converge and more and more functionality comes from the outside with LTI 2.0 - having a highly usable and attractive portal will be of crtitical importance to our future. 

So - lets first agree if you (and others) are for or against skin sets that are switchable with a single property.

Once we make that decision - it becomes a question of *how* to do it - and I bet we will find a better way to do it now that we have a little experience.  I am 100% open to a better approach to skin sets in 2.9 + - I am pretty much not open to "no skin sets in 2.9+".

Already in this discussions I am thinking there might be a "best of both ideas" - but lets resolve the "skin sets - to be or not to be".

/Chuck

On Mar 19, 2013, at 7:24 PM, Steve Swinsburg wrote:

> I'm still confused about what you are trying to argue for here Chuck.
> 
> Here are three things I think you might be saying:
> 
> Possibility 1: That skin names need to be aligned between 2.8 and 2.9+?. Ie default in 2.8, neo-default in 2.9. default-horiz in 2.8, neo-default-horiz in 2.9
> 
> I don't think it matters if the skin names that come with Sakai out of the box are aligned, they are completely different. And most people would create their own anyway. See also Possibility 3 below.
> 
> 
> Possibility 2: That skins from 2.8 will still work in the neoskin portal?
> 
> That isn't the case, skins from 2.8 need to be updated to work in neoskin templates.
> 
> Here is a real scenario of why all of this is confusing.
> 
> Suppose the following sakai.properties:
> 
> portal.templates=neoskin
> skin.default=someskin
> 
> Currently, the portal will change this to be neo-someskin. So really my skin needs to be called neo-someskin. So its against what I set, that skin doesn't exist and I get no skin. Confusing.
> 
> Then I realise my mistake and go and either change my skin to neo-someskin or just change the property to neo-someskin since 'neo-' isn't appended twice
> 
> So now I have:
> 
> portal.templates=neoskin
> skin.default=neo-someskin
> 
> And everything works.
> 
> Now, in a site, I want to have a custom skin, so I set the property to 'neo-someotherskin' (because I remembered the portal prefixing thing and my skin is named correctly). So I have this site rendering as neo-someotherskin, and other sites rendering as neo-someskin. Cool.
> 
> Now someone changes my site skin to someoldskin. The portal prefixes it to neo-someoldskin and it breaks. But I cant just change my skin name to neo-someold28skin because that skin is for the older portal and needs to be adjusted to work in the neo portal. So I cant just reuse my old skins without changing them.
> 
> The point here is that portal.templates is always respected. There is no changing of the templates to suit the skin. So ALL skins must be compatible with whatever templates you have set in sakai.properties.
> 
> Therefore this prefixing is confusing and unnecessary, and I still need to make new skins that are compatible.
> 
> 
> Possibility 3: That when people upgrade their skin site property will still work and be automatically prefixed.
> 
> So this would be the case above where someone had set 'someoldskin' as the site property. Then they upgrade Sakai and that site no longer has a skin because
> 
> portal.templates=neoskin
> 
> and the site property becomes 'neo-someoldskin', that skin doesn't exist, and we get a string of text down the screen with no CSS whatsoever. This happened to me yesterday.
> 
> If we did upgrade 'someoldskin' to 'somenewskin' and adjusted the site property, then it still wouldn't work since it would still be prefixed with neo- to become 'neo-somenewskin'. So people are now tied in to using the neo- prefix (or whatever other prefix they want, but only ONE prefix) because it gets prefixed.
> 
> 
> Again, the prefix is unnecessary. Why cant I just set 'somenewskin' as my site property and be done with it? Why should I be restricted in calling my skins 'prefix-someskinname'? Does anyone really care that 'mycoolskin' maps to 'neo-mycoolskin' and looks nice in a directory structure? I should be able to call my skins somecoolskin-for-29 and somecoolskin-for-210, or somecoolskin-for-29-v2 or whatever I wanted to.
> 
> regards,
> Steve
> 
> 
> On Wed, Mar 20, 2013 at 8:48 AM, Charles Severance <csev at umich.edu> wrote:
> 
> 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/20130320/239b3af0/attachment.html