[Building Sakai] Portal NEO Prefix

[Steve Swinsburg]

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/301329f0/attachment.html