[Building Sakai] Portal NEO Prefix

[Steve Swinsburg]

Hi Chuck,

The whole point of the argument is that you cannot have skins for different templates active at the same time. So even if you had neo-someskin (for 2.9+) and someskin (for 2.8 and earlier), it doesn't matter. They both *cannot* work at the same time because the portal templates cannot be changed at runtime.

I don't understand why we are imposing a naming convention? It's just CSS, add a comment at the top of the portal.css for each skin or add a readme that lists what each does? There seems to be a fascination with the names being similar, why does that matter?

I dont propose any naming conventions be applied at all, exactly the opposite actually. Let people call skins whatever they want as they have done forever. It will work. The only properties I propose are the existing ones:

# switch between the new 2.9 portal and the old 2.8 one if you want to
portal.templates=…

# the name of the skin to use by default. sites can set their own skin if they want to
default.skin=…

As for SQL to adjust a skin set that a site has, unless the skin is incompatible with the templates in use then it's not needed. And a simple scan of the props table will tell you if someone is using a skin that is incompatible. It should all be taken care of at upgrade time.

Again, there is *no* way for a skin that is currently in use to be automatically mapped to the neo equivalent. Work must be done to make a compatible version.

Another real example:

In 2.8 I have a site with a custom skin called alphabet. I upgraded to 2.9 and the portal changed the name of that skin to neo-alphabet. This does *not* work. I don't have a skin called neo-alphabet. My site is broken, there is no CSS. So I need to actually do work to upgrade my skin/make a new one. But again I should be able to call my new skin whatever I want, and in this particular case I called my skin alphabet-v2. 

cheers,
S







On 21/03/2013, at 3:34 PM, Charles Severance <csev at umich.edu> wrote:

> 
> On Mar 21, 2013, at 12:13 AM, Steve Swinsburg wrote:
> 
>> Hi Chuck
>> 
>> I can see that skin sets might be useful for some that might want to switch back and forth between portal templates, but still don't see the point of a fixed prefix. I can switch between skins with no issue, except for the prefix.
> 
> 
>> Fwiw my old skins are there and my new ones are there too. I have about 30 of them. I have a readme about what skins are what. I don't need a hardcoded prefix to remind me what they are as they are named appropriately, ie someskin29. 
> 
> Sounds like you use a suffix and if I had make the setting a suffix instead of a prefix - then my design would be perfect :)  Just kidding.
> 
> Tell me in detail what properties could we add/or alter that would switch skinsets easily that eliminates the prefix.  Assume you have 28, neo, and xslt templates and skins in the code base at the same time and have multiple skins for each template (say law, medicine, and engineering) and trying to keep all three skins working for all three templates (i.e. nine skins) - and you are a school that uses the skin picker in site setup.  Because that is the rules for how the trunk functions.   All skins work in all templates all the time.  I understand that a particular school only has to have one set of properties and skins that actually work at any given moment - but in trunk I need them to work simultaneously.
> 
> How would you name the skins and how would you design the properties to switch skin sets - tell me the exact conventions, file names and properties you would propose.  Give me exact file names and property settings that address the above use cases.  Make sure to address any SQL that is needed to adjust site properties to reflect a skin set change.  Also if swapping skin sets entails moving / renaming files - detail that too.
> 
> /Chuck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130321/8fee48d3/attachment.html