[Building Sakai] Portal NEO Prefix

Poindexter, David Ray davpoind at iupui.edu
Thu Mar 21 15:36:33 PDT 2013


I don't want it set or unset. I just want a consensus. I've got other devs asking me "why is my tool all broken" and I'm trying to explain this complicated neo prefixing thing.

The OSP tool, for example.

If we could just say "yes, we're doing the neo prefix thing" or "no, there's a better way" (I think there is, but I have no weight here) it would make things SO much easier.

As an aside, you all did just release 2.9.1 a few weeks ago, right? Why are we only now asking about this prefix? Some kind of delayed reaction thing, I'm guessing?
--
David Poindexter
Systems Analyst
Enterprise Student Systems
UITS
Indiana University
535 West Michigan Street
Indianapolis, IN 46202-5157
O: 317.274.8686
W: http://uits.iu.edu<http://uits.iu.edu/>

From: Steve Swinsburg <steve.swinsburg at gmail.com<mailto:steve.swinsburg at gmail.com>>
Date: Thursday, March 21, 2013 6:25 PM
To: David Poindexter <davpoind at iupui.edu<mailto:davpoind at iupui.edu>>
Cc: Matthew Jones <matthew at longsight.com<mailto:matthew at longsight.com>>, Sakai Dev <sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org>>
Subject: Re: [Building Sakai] Portal NEO Prefix

Well I was trying to make this the longest thread in history ;)

IIRC portal.neoprefix has a default value so you can't unset it to empty. Though I haven't got the code in front of me. Perhaps we fix that (One line fix). Though I still reckon its unnecessary ;)

Sent from my iPhone

On 22/03/2013, at 8:30, "Poindexter, David Ray" <davpoind at iupui.edu<mailto:davpoind at iupui.edu>> wrote:

If you call could fix stuff and come to an agreement, that'd be swell.

Seriously, I'm not looking forward to continuing to figure out the "sakai" way versus the individual tool's way of doing things. I've resolved about the last "path" issue that I care to address.

What is a skin? What should it override and inherit from? Where should it be defined? Figure this out and get back to us (the rest of the user community), and please put a rush on this order. This has gotten to be both inane and counterproductive.

Please just come to a decision and let the rest of us move on with important issues. Please!
--
David Poindexter
Systems Analyst
Enterprise Student Systems
UITS
Indiana University
535 West Michigan Street
Indianapolis, IN 46202-5157
O: 317.274.8686
W: http://uits.iu.edu<http://uits.iu.edu/>

From: Matthew Jones <matthew at longsight.com<mailto:matthew at longsight.com>>
Date: Thursday, March 21, 2013 12:41 PM
To: Steve Swinsburg <steve.swinsburg at gmail.com<mailto:steve.swinsburg at gmail.com>>
Cc: Sakai Dev <sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org>>
Subject: Re: [Building Sakai] Portal NEO Prefix

I think what you're describing at the bottom here was the motivation for the auto-append, trying to support both systems concurrently.

Say we have an existing school with 10 skins. When they upgrade to 2.9 they either.

1) Leave all the skins as is, adjust a property and stay with the old templates.
2) Update all of the skins to 2.9 style, append neo- to all of them (or changed portal.neoprefix which is by default neo-) then switch to the new templates.

Otherwise they'd have to run a DB conversion ONLY when they're ready to make the switch and ONLY if they decide to put the templates into new directories. If you have a skin called alphabet, you need to create a new skin called alphabet. The place to put it (neo-alphabet) was just the convention. Nobody provided that conversion script or any better process around it. We didn't expect people to read the documentation (like most probably didn't even for this change) even though I wrote it well over 6 months ago and just now it's coming up. (https://confluence.sakaiproject.org/display/DOC/Sakai+CLE+2.9+portal+changes) I'm personally happy with the properties and the process "as-is"

I also don't think it would be too difficult to have both old and new vm templates be able to work in the same system, but I think the consensus will be to delete the old templates in 2.10 anyway as they're much better. If you don't want any prefix you probably can just set

portal.neoprefix=

And you then need to either in-place replace all of the skins or write a conversion script for SAKAI_SITE, or else they would break custom skins as you describe for any old ones that aren't updated. At least *with* a prefix or with a skin column database conversion the break is obvious, which is better and typically just a few minutes to get the css looking good.

The problem Dave Adams describes in the other thread was a problem before this neo portal and *usualy* didn't come up because this default/tool.css was just left as is and the same by convention for everyone.

On Thu, Mar 21, 2013 at 8:26 AM, Steve Swinsburg <steve.swinsburg at gmail.com<mailto:steve.swinsburg at gmail.com>> wrote:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130321/6e338918/attachment.html 


More information about the sakai-dev mailing list