[Building Sakai] jQuery 1.1.4 > 1.3.2 Upgrade for 2.7?

[Steve Swinsburg]

The only issue I have (with my own suggestion) is for offline startups  
where the referenced file isn't cached.

A while ago we were referencing a DTD for JSF which caused offline  
startups to bail. Maybe we need an online/offline sakai property so  
online it goes out and grabs a central copy, offline it uses a bundled  
version. Again this means the bundled version needs to be kept up to  
date which is back to where we started!

cheers,
Steve



On 17/07/2009, at 7:43 PM, Eli Cochran wrote:

> Lance,
> I wondered about that. It's a good idea... how to other people feel
> about relying on an external repository for production?
>
> On a slightly different topic... For 3.0 we should reference something
> like Fluid's Infusion-all.js which contains jQuery plus all of Fluid,
> plus a bit of jQuery UI, but for 2.6 this is probably overkill.
>
> - Eli
>
> On Jul 17, 2009, at 11:10 AM, Speelmon, Lance Day wrote:
>
>> Agreed - what if we just reference the central versions from google -
>> this would allow projects to use their own versions while gaining the
>> benefits of having jquery in cache...  Thoughts?  L
>>
>> e.g.:
>>
>> <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/
>> jquery.js" type="text/javascript"></script>
>>
>>
>>
>> Lance Speelmon
>> Scholarly Technologist
>>
>> On Jul 16, 2009, at 6:03 AM, Steve Swinsburg wrote:
>>
>>> It would be nice for every project that uses jQuery to use a central
>>> one, that way it is probably cached by the time you get to it so it
>>> will make loading even faster.
>>> But as noted, it gets dated real quick so projects ship their own.
>>> Library upgrades like these we need to keep on top of. Most don't
>>> break backwards functionality unless you are binding to a really old
>>> version to begin with.
>>>
>>> +1 to Clay's suggestion, upgrade early (now), and get any issues
>>> resolved early. Likewise for the other libraries we need to
>>> upgrade(commons-lang et al)
>>>
>>>
>>> cheers,
>>> Steve
>>>
>>> ---
>>> Steve Swinsburg
>>> Portal Systems Developer
>>> Centre for e-Science
>>> Lancaster University
>>> Lancaster
>>> LA1 4YT
>>>
>>> email: s.swinsburg at lancaster.ac.uk
>>> phone: +44 (0) 1524 594870
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 16 Jul 2009, at 08:51, Stephen Marquard wrote:
>>>
>>>> Upgrading the portal seems easy, especially if Eli has committed to
>>>> pursue any resulting issues. Eli, can you create a JIRA for this?
>>>>
>>>> The question really is whether we continue with a shared version  
>>>> for
>>>> multiple projects, or let each project do its own thing  
>>>> (referencing
>>>> a specific version). Some projects have bundled newer versions
>>>> anyway, so perhaps that's inevitable.
>>>>
>>>> Cheers
>>>> Stephen
>>>>
>>>>
>>>>
>>>>
>>>> Stephen Marquard, Learning Technologies Co-ordinator
>>>> Centre for Educational Technology, University of Cape Town
>>>> http://www.cet.uct.ac.za
>>>> Email/IM/XMPP: stephen.marquard at uct.ac.za
>>>> Phone: +27-21-650-5037 Cell: +27-83-500-5290
>>>>>>> Eli Cochran <eli at media.berkeley.edu> 7/16/2009 2:34 AM >>>
>>>> Hi folks,
>>>> Every time that I notice that the Portal is using jQuery 1.1.4, I
>>>> cringe. This version, while very stable, is very old (August 2007).
>>>> The current version is 1.3.2 released in Feb 2009. This version is
>>>> also very stable and much, much faster.
>>>>
>>>> I'd like to suggest that we upgrade to 1.3.2 for 2.7. By the time
>>>> there may be jQuery 1.4 or even the mythical jQuery 2.0 but even
>>>> 1.3.2
>>>> would be a huge step forward.
>>>>
>>>> There is usually a fair amount of backwards compatibility in  
>>>> jQuery.
>>>> However, this is a big jump and I suspect that there will be some
>>>> issues. I'm happy to take responsibility for any portal problems
>>>> that
>>>> emerge.
>>>>
>>>> The bigger issue is what to do with bugs that come up in tools that
>>>> might be utilizing /library/js/jquery.js. That is a bigger risk.
>>>>
>>>> Any thoughts?
>>>>
>>>> - Eli
>>>>
>>>> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>>>>
>>>> Eli Cochran
>>>> user interaction developer
>>>> ETS, UC Berkeley
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>>>> with a subject of "unsubscribe"
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>>> with a subject of "unsubscribe"
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>> with a subject of "unsubscribe"
>
> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"