[Building Sakai] jQuery 1.1.4 > 1.3.2 Upgrade for 2.7?
Noah Botimer
botimer at umich.edu
Fri Jul 17 13:04:01 PDT 2009
I don't think we should be shipping bundles with external URL
dependencies baked in. Using the Google URLs works great in hosted
apps, but I'm concerned about ripples once we zip it up. It may be
possible to ship a copy and offer a switch for implementors, though,
as an emergency valve if the URLs stop working.
Specific to the upgrade, the biggest thing I've noticed (through
1.1.2, 1.2.1, 1.3.2) is the removal of the @-symbol in attribute
selectors. Everything else seems pretty backward-compatible for me.
The attribute selectors can cause a good bit of headache, though,
since they're somewhat difficult to grep for. We would need some
dedicated testing and resolution effort.
I am definitely in favor of the upgrade. The synergy with jQuery UI
and Fluid is strong and valuable in a number of ways, not to mention
the performance, documentation, and flexibility gains of using a more
recent version.
Thanks,
-Noah
On Jul 17, 2009, at 2: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"
>
>
More information about the sakai-dev
mailing list