Side note. Multiple versions of jQuery can live happily on the same page.
jQuery handles isolation and noConflict so well that it can work on the
same page as incompatible versions of itself (which isn't the case for
basically any other js library, 90% of which prototype stuff in).

I like to use a variable like `jQuery13`, basically saving the jQuery
variable in an alternate variable identified by major version number.
Should an upgrade come along it's a little easier to migrate code.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

Tim Starling wrote:
> Michael Dale wrote:
>   
>> That is part of the idea of centrally hosting reusable client-side 
>> components so we control the jquery version and plugin set. So a
>> new version won't "come along" until its been tested and
>> integrated.
>>     
>
> You can't host every client-side component in the world in a
> subdirectory of the MediaWiki core. Not everyone has commit access to
> it. Nobody can hope to properly test every MediaWiki extension.
>
> Most extension developers write an extension for a particular site,
> and distribute their code as-is for the benefit of other users. They
> have no interest in integration with the core. If they find some
> jQuery plugin on the web that defines an interface that conflicts with
> MediaWiki, say jQuery.load() but with different parameters, they're
> not going to be impressed when you tell them that to make it work with
> MediaWiki, they need to rewrite the plugin and get it tested and
> integrated.
>
> Different modules should have separate namespaces. This is a key
> property of large, maintainable systems of code.
> ...
> -- Tim Starling
>   


-- 
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to