Skin & JS cleanup and jQuery - Wikitech-l

Michael Dale

15 Apr 15 Apr

9:29 p.m.

These changes will probably result in some minor adjustments to existing skins. (I will try not to completely break compatibility cuz I know there are many custom skins out in the wild that would be no fun to stop working once they update medaiWiki) This consolidation of <head> includes _may_ result in _some_ un-updated skins referencing the same files twice which I think most browsers genneraly handle "oky" Enabling $wgEnableScriptLoader will not work so well with skins that have not been updated. Should have a patch soon. more about scriptLoader: http://www.mediawiki.org/wiki/ScriptLoader (We will most likely ship with $wgEnableScriptLoader off by default ) I am also very excited about jQuery making its way into core. Things like the add_media_wizard are much easier to put together with jQuery's nifty abstractions and msg system. More about add media wizard: http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wi… peace, michael Brion Vibber wrote:

...

Just a heads-up -- Michael Dale is working on some cleanup of how the various JavaScript bits are loaded by the skins to centralize some of the currently horridly spread-out code and make it easier to integrate in a centralized loader so we can serve more JS together in a single compressed request. Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component. The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net savings. If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply

Hay (Husky)

10:53 p.m.

That's great news. I've been programming in JavaScript quite a lot the last few years and i think i would've probably gone insane if i hadn't discovered jQuery. Especially for complex and intricate HTML selections it's pretty amazing what you can do with jQuery. Also, the fact that animations are built into the core could mean it might get a little bit more simple to do visually cool things, which might make the UI more intuitive. -- Hay On Wed, Apr 15, 2009 at 11:45 PM, Sergey Chernyshev <sergey.chernyshev(a)gmail.com> wrote:

...

Guys, It's great to see that you're working in this direction - I'm thinking about working on this for a while, but didn't have a gut to undertake such ambitious project alone ;) Do you have a working instance of ScriptLoader anywhere so I can aim some performance tools at it? Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Wed, Apr 15, 2009 at 5:29 PM, Michael Dale <mdale(a)wikimedia.org> wrote:

These changes will probably result in some minor adjustments to existing skins. (I will try not to completely break compatibility cuz I know there are many custom skins out in the wild that would be no fun to stop working once they update medaiWiki) This consolidation of <head> includes _may_ result in _some_ un-updated skins referencing the same files twice which I think most browsers genneraly handle "oky" Enabling $wgEnableScriptLoader will not work so well with skins that have not been updated. Should have a patch soon. more about scriptLoader: http://www.mediawiki.org/wiki/ScriptLoader (We will most likely ship with $wgEnableScriptLoader off by default ) I am also very excited about jQuery making its way into core. Things like the add_media_wizard are much easier to put together with jQuery's nifty abstractions and msg system. More about add media wizard: http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wi… peace, michael Brion Vibber wrote:

Just a heads-up -- Michael Dale is working on some cleanup of how the various JavaScript bits are loaded by the skins to centralize some of the currently horridly spread-out code and make it easier to integrate in a centralized loader so we can serve more JS together in a single compressed request. Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component. The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net

savings.

If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Reply

Chad

6:44 p.m.

On Thu, Apr 16, 2009 at 2:35 PM, Sergey Chernyshev <sergey.chernyshev(a)gmail.com> wrote:

...

Speaking of libraries and all, I think it's worth merging libraries in general and figuring out a way for skin and extension developers to include libraries in the way that system can only: - include a library once - include latest library unless absolutely necessary - maybe even load parts of the library on demand ( http://developer.yahoo.com/yui/yuiloader/ is an example of what I'm talking about). Maybe it's also worth adding some JS bundles functionality where main bundle is global JS to be loaded on all page and there can be more bundles to load the rest of the code on pages that need them. My point is that this decision could be made in MW and not in the extensions - system should know what is bundled where and ignore inclusion request on the page if, let's say, YUI is already loaded in main bundle. Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Wed, Apr 15, 2009 at 6:53 PM, Hay (Husky) <huskyr(a)gmail.com> wrote:

That's great news. I've been programming in JavaScript quite a lot the last few years and i think i would've probably gone insane if i hadn't discovered jQuery. Especially for complex and intricate HTML selections it's pretty amazing what you can do with jQuery. Also, the fact that animations are built into the core could mean it might get a little bit more simple to do visually cool things, which might make the UI more intuitive. -- Hay On Wed, Apr 15, 2009 at 11:45 PM, Sergey Chernyshev <sergey.chernyshev(a)gmail.com> wrote:

Guys, It's great to see that you're working in this direction - I'm thinking

about

working on this for a while, but didn't have a gut to undertake such ambitious project alone ;) Do you have a working instance of ScriptLoader anywhere so I can aim some performance tools at it? Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Wed, Apr 15, 2009 at 5:29 PM, Michael Dale <mdale(a)wikimedia.org>

wrote:

> These changes will probably result in some minor adjustments to existing > skins. (I will try not to completely break compatibility cuz I know > there are many custom skins out in the wild that would be no fun to stop > working once they update medaiWiki) > > This consolidation of <head> includes _may_ result in _some_ un-updated > skins referencing the same files twice which I think most browsers > genneraly handle "oky" > > Enabling $wgEnableScriptLoader will not work so well with skins that > have not been updated. Should have a patch soon. more about

scriptLoader:

> http://www.mediawiki.org/wiki/ScriptLoader > (We will most likely ship with $wgEnableScriptLoader off by default ) > > I am also very excited about jQuery making its way into core. Things > like the add_media_wizard are much easier to put together with jQuery's > nifty abstractions and msg system. More about add media wizard: > >

http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wi…

> > peace, > michael > > > Brion Vibber wrote: > > Just a heads-up -- > > > > Michael Dale is working on some cleanup of how the various JavaScript > > bits are loaded by the skins to centralize some of the currently > > horridly spread-out code and make it easier to integrate in a > > centralized loader so we can serve more JS together in a single > > compressed request. > > > > Unless there's a strong objection I'd be very happy for this to also > > include loading up the jQuery core library as a standard component. > > > > The minified jQuery core is 19k gzipped, and can simplify other JS

code

> > significantly so we can likely chop down wikibits.js, mwsuggest.js,

and

> the site-customized Monobook.js files by a large margin for a net savings. > > If you've done browser-side JavaScript development without jQuery and > wanted to kill yourself, I highly recommend you try jQuery -- it's > sooooo nice. :) > > -- brion > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

FWIW, if jQuery or any other JS libraries are being bundled into core software, extensions in SVN should be updated to not load them anymore, as they library will already be at their disposal. Same goes for other non-JS bundled code, if any exists. -Chad

Reply

Michael Dale

8:17 p.m.

I have a branch I have made some initial commits to.. http://svn.wikimedia.org/viewvc/mediawiki/branches/script-loader/ (Its not ready yet)...will be great to have some tests to compare it with... I will be sure to let you know when it is ready ;) peace, michael Sergey Chernyshev wrote:

...

Guys, It's great to see that you're working in this direction - I'm thinking about working on this for a while, but didn't have a gut to undertake such ambitious project alone ;) Do you have a working instance of ScriptLoader anywhere so I can aim some performance tools at it? Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Wed, Apr 15, 2009 at 5:29 PM, Michael Dale <mdale(a)wikimedia.org> wrote:

These changes will probably result in some minor adjustments to existing skins. (I will try not to completely break compatibility cuz I know there are many custom skins out in the wild that would be no fun to stop working once they update medaiWiki) This consolidation of <head> includes _may_ result in _some_ un-updated skins referencing the same files twice which I think most browsers genneraly handle "oky" Enabling $wgEnableScriptLoader will not work so well with skins that have not been updated. Should have a patch soon. more about scriptLoader: http://www.mediawiki.org/wiki/ScriptLoader (We will most likely ship with $wgEnableScriptLoader off by default ) I am also very excited about jQuery making its way into core. Things like the add_media_wizard are much easier to put together with jQuery's nifty abstractions and msg system. More about add media wizard: http://metavid.org/blog/2009/03/27/add-media-wizard-and-firefogg-on-test-wi… peace, michael Brion Vibber wrote:

Just a heads-up -- Michael Dale is working on some cleanup of how the various JavaScript bits are loaded by the skins to centralize some of the currently horridly spread-out code and make it easier to integrate in a centralized loader so we can serve more JS together in a single compressed request. Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component. The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net

savings.

If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Reply

Michael Dale

10:53 p.m.

oky... branch /branches/script-loader/ ready for wider testing after you check out the branch you have to add $wgEnableScriptLoader = true; to your local settings. Things I don't tackle in this version of the scriptLoader: 1) checking the version of every msg string packaged in JS (right now I will just rely on bumping the $wgStyleVersion up global var to clear caches as not many projects besides mine are using JavaScript msg packing system yet ;) ... and there are other issues with the language packaging that need to be addressed. But I do check the latest revision id for every wiki page that is included via the scriptLoader. This has the nice benefit of once you save a gadget preference or update a user javascript page you don't have to "shift reload" as a new unique javascript request id is automatically generated. 2) Style sheet grouping is a bit tricky cuz you have to rewrite all the relative paths to a different relative position since its being served from the script server location. There is a library that handles this: http://code.google.com/p/minify/source/browse/trunk/min/lib/Minify/CSS.php but i have not integrated that yet...so style sheets are still individually requested. If we really want all the style sheets grouped I can bump that on the priority list to right after the upload api stuff that I have to finish up ;) --michael Brion Vibber wrote:

...

Just a heads-up -- Michael Dale is working on some cleanup of how the various JavaScript bits are loaded by the skins to centralize some of the currently horridly spread-out code and make it easier to integrate in a centralized loader so we can serve more JS together in a single compressed request. Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component. The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net savings. If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply

Marco Schuster

7:11 p.m.

On Fri, Apr 17, 2009 at 1:38 PM, Aryeh Gregor <Simetrical+wikilist@gmail.com<Simetrical%2Bwikilist@gmail.com>

...

wrote:

> On Thu, Apr 16, 2009 at 6:35 PM, Marco Schuster > <marco(a)harddisk.is-a-geek.org

...

wrote:

> > Are there any plans to use Google Gears for storage on clients? Okay, > people > > have to enable it by hand, but it shoulda speed up page loads for people > > very much (at least for those who use it). > > What, specifically, would be stored in Google Gears? Would HTML5's > localStorage also be suitable? > Isn't GG supposed to be an implementation of localStorage for browsers who don't support it yet (does any browser support localStorage *now*, btw?)? What could be stored is JS bits likely not to change THAT often, i.e. if Wikipedia is ever going to make a WYSIWYG editor available (Wikia has it!!!) its JS files could be cached, same for those tiny little flag icons , the wikipedia ball, the background of the page... maybe even some parts of the sitewide CSS. Actually, it could be expanded to store whole articles (then simply copy over or enhance http://code.google.com/intl/de-DE/apis/gears/articles/gearsmonkey.html - I'm gonna modify it for german Wikipedia when i've got some time). Marco -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de

Reply

Brion Vibber

9:42 p.m.

On 4/16/09 3:35 PM, Marco Schuster wrote:

...

Are there any plans to use Google Gears for storage on clients? Okay, people have to enable it by hand, but it shoulda speed up page loads for people very much (at least for those who use it).

For those not familiar with it, Google Gears provides a few distinct capabilities to client-side JavaScript code. Equivalents of these features are being standardized in HTML 5 / WHATWG work, and some of them are already available in some production browsers without installing a separate extension. (Note that the first usage of Gears services on a site requires user interaction -- the user must click through a permission dialog -- so while you can make use of them for 'progressive enhancement' you can't do so transparently. The same isn't necessarily true of browsers implementing them natively.) * Caching static files locally under application control ('LocalServer') Most of the time not a huge win over simply setting decent caching headers. Main advantage is if you want to provide an offline mode for your application, you're more likely to actually have the resources you need since you can pre-fetch them and control expiration. Note there has been some experimental work on hacking some offline viewing/editing with Gears into MediaWiki: http://wiki.yobi.be/wiki/Mediawiki_LocalServer but a really full implementation would be hard to hack into our architecture. * Client-side SQLite database Local database storage can be useful for various things like local edit drafts, storage of data for offline viewing, etc. Note that anything stored client-side is *not* automatically replicated to other browsers, so it's not always a good choice for user-specific data since people may hop between multiple computers/devices/browsers. * Background JavaScript worker threads Not super high-priority for our largely client-server site. Can be useful if you're doing some heavy work in JS, though, since you can have it run in background without freezing the user interface. * Geolocation services Also available in a standardized form in upcoming Firefox 3.5. Could be useful for geographic-based search ('show me interesting articles on places near me') and 'social'-type things like letting people know about local meetups (like the experimental 'geonotice' that's been running sometimes on the watchlist page). -- brion

Reply

Brion Vibber

22 Apr 22 Apr

4:18 p.m.

On 4/17/09 6:45 PM, Marco Schuster wrote:

...

On Fri, Apr 17, 2009 at 11:42 PM, Brion Vibber<brion(a)wikimedia.org> wrote:

* Background JavaScript worker threads

You mean...stuff like bots written in Javascript, using the XML API? I could imagine also sending mails via Special:Emailuser in the background to reach multiple recipients - that's a PITA if you want send mails to multiple users.

Perhaps... but note that the i/o for XMLHTTPRequest is asynchronous to begin with -- it's really only if you're doing heavy client-side _processing_ that you're likely to benefit from a background worker thread. (Background threads also cannot directly touch the DOM or any objects in your foreground thread. You need to pass stuff in and out through indirect messages.)

...

* Geolocation services

That sounds kinda interesting, even if the accuracy on non-GPS-enabled devices isn't that high... can this in any way be joined with the OSM integration?

It sure could! :) -- brion

Reply

Brian

4:28 p.m.

Many extensions are now using the Yahoo User Interface library. It would be nice if mediawiki included it by default. On Wed, Apr 15, 2009 at 3:05 PM, Brion Vibber <brion(a)wikimedia.org> wrote:

...

Just a heads-up -- Michael Dale is working on some cleanup of how the various JavaScript bits are loaded by the skins to centralize some of the currently horridly spread-out code and make it easier to integrate in a centralized loader so we can serve more JS together in a single compressed request. Unless there's a strong objection I'd be very happy for this to also include loading up the jQuery core library as a standard component. The minified jQuery core is 19k gzipped, and can simplify other JS code significantly so we can likely chop down wikibits.js, mwsuggest.js, and the site-customized Monobook.js files by a large margin for a net savings. If you've done browser-side JavaScript development without jQuery and wanted to kill yourself, I highly recommend you try jQuery -- it's sooooo nice. :) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply

Brion Vibber

4:42 p.m.

On 4/22/09 9:33 AM, Sergey Chernyshev wrote:

...

Exactly because this is the kind of requests we're going to get, I think it makes sense not to have any library bundled by default, but have a centralized handling for libraries, e.g. one extension asks for latest jQuery and latest YUI and MW loads them, another extension asks for jQuery only and so on.

Considering we want core code to be able to use jQuery, I think the case for bundling it is pretty strong. :) -- brion

Reply

Sergey Chernyshev

4:52 p.m.

Yep, with jQuery in the core it's probably best to just bundle it. There is another issue with the code loading and stuff - making JS libraries call a callback function when they load and all the functionality to be there instead of relying on browser to block everything until library is loaded. This is quite advance thing considering that all the code will have to be converted to this model, but it will allow for much better performance when implemented. Still it's probably "Phase 5" kind of optimization, but it can bring really good results considering JS being the biggest blocker. More on the topic is on Steve Souders' blog: http://www.stevesouders.com/blog/2008/12/27/coupling-async-scripts/ Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Wed, Apr 22, 2009 at 12:42 PM, Brion Vibber <brion(a)wikimedia.org> wrote:

...

On 4/22/09 9:33 AM, Sergey Chernyshev wrote:

Exactly because this is the kind of requests we're going to get, I think

it

makes sense not to have any library bundled by default, but have a centralized handling for libraries, e.g. one extension asks for latest jQuery and latest YUI and MW loads them, another extension asks for

jQuery

only and so on.

Considering we want core code to be able to use jQuery, I think the case for bundling it is pretty strong. :) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply

Michael Dale

5:21 p.m.

The mv_embed.js includes a doLoad function that matches the autoLoadJS classes listed in mediaWiki php. So you can dynamically "autoload" arbitrary "sets" of classes (js-files in the mediaWiki software) in a single http request and then run something once they are loaded. It can also "autoload" sets of wiki-titles for user-space scripts again in a single request grouping, localizing, gziping and caching all the requested wiki-title js in a single request. This is nifty cuz say your script has localized msg. You can fill these in in user-space MediaWiki:myMsg then put them in the header of your user-script, then have localized msg in user-space javascript ;) .. When I get a chance I will better document this ;) But its basically outlined here: http://www.mediawiki.org/wiki/Extension:ScriptLoader The link you highlight appears to be about running stuff once the page is ready. jQuery includes a function $(document).ready(function(){ //code to run now that the dom-state is ready }) so your enabled gadget could use that to make sure the dom is ready before executing some functions. (Depending on the type of js functionality your adding it /may/ be better to load on-demand once a new interface component is invoked rather than front load everything. Looking at the add-media-wizard gadget on testing.wikipedia.org for an idea of how this works. peace, --michael Sergey Chernyshev wrote:

...

Yep, with jQuery in the core it's probably best to just bundle it. There is another issue with the code loading and stuff - making JS libraries call a callback function when they load and all the functionality to be there instead of relying on browser to block everything until library is loaded. This is quite advance thing considering that all the code will have to be converted to this model, but it will allow for much better performance when implemented. Still it's probably "Phase 5" kind of optimization, but it can bring really good results considering JS being the biggest blocker. More on the topic is on Steve Souders' blog: http://www.stevesouders.com/blog/2008/12/27/coupling-async-scripts/ Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Wed, Apr 22, 2009 at 12:42 PM, Brion Vibber <brion(a)wikimedia.org> wrote:

On 4/22/09 9:33 AM, Sergey Chernyshev wrote:

Exactly because this is the kind of requests we're going to get, I think

it

makes sense not to have any library bundled by default, but have a centralized handling for libraries, e.g. one extension asks for latest jQuery and latest YUI and MW loads them, another extension asks for

jQuery

only and so on.

Considering we want core code to be able to use jQuery, I think the case for bundling it is pretty strong. :) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Reply

Michael Dale

6:43 p.m.

hmm right... The idea of the scriptLoader is we get all our #1 included javascript in a single request. So we don't have round trips that would benefit as much from lazy loading so no need to rewrite stuff that is included that way already. I don't think we are proposing convert all scripts to #2 or #3 loading... We already have the importScriptURI function which script use for loading when not using #1. I do suggest we move away from importScriptURI to something like the doLoad function in mv_embed ... that way we can load multiple js files in a single request using the mediaWiki scriptServer (if its enabled). Right now all the importScriptURI stuff works non-blocking and included scripts need to include code to execute anything they want to run. To make things more maintainable and modular we should transition to objects/classes providing methods which can be extended and autoloaded rather than lots of single files doing lots of actions on the page in a less structured fashion. But there is no rush to transition as the scripts are "working" as is and the new infrastructure will "work" with the scripts as they are. But the idea of the new infrastructure is to support that functionality in the future... --michael Sergey Chernyshev wrote:

...

No, my link is about 3 ways of loading: 1. Normal script tags (current style) 2. Asynchronous Script Loading (loading scripts without blocking, but without waiting for onload) 3. Lazyloading (loading script onload). Number 2 might be usable as well. In any case changing all MW and Extensions code to work for #2 or #3 might be a hard thing. Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Wed, Apr 22, 2009 at 1:21 PM, Michael Dale <mdale(a)wikimedia.org> wrote:

The mv_embed.js includes a doLoad function that matches the autoLoadJS classes listed in mediaWiki php. So you can dynamically "autoload" arbitrary "sets" of classes (js-files in the mediaWiki software) in a single http request and then run something once they are loaded. It can also "autoload" sets of wiki-titles for user-space scripts again in a single request grouping, localizing, gziping and caching all the requested wiki-title js in a single request. This is nifty cuz say your script has localized msg. You can fill these in in user-space MediaWiki:myMsg then put them in the header of your user-script, then have localized msg in user-space javascript ;) .. When I get a chance I will better document this ;) But its basically outlined here: http://www.mediawiki.org/wiki/Extension:ScriptLoader The link you highlight appears to be about running stuff once the page is ready. jQuery includes a function $(document).ready(function(){ //code to run now that the dom-state is ready }) so your enabled gadget could use that to make sure the dom is ready before executing some functions. (Depending on the type of js functionality your adding it /may/ be better to load on-demand once a new interface component is invoked rather than front load everything. Looking at the add-media-wizard gadget on testing.wikipedia.org for an idea of how this works. peace, --michael Sergey Chernyshev wrote:

Yep, with jQuery in the core it's probably best to just bundle it. There is another issue with the code loading and stuff - making JS

libraries

call a callback function when they load and all the functionality to be there instead of relying on browser to block everything until library is loaded. This is quite advance thing considering that all the code will

have

to be converted to this model, but it will allow for much better

performance

when implemented. Still it's probably "Phase 5" kind of optimization, but

it

can bring really good results considering JS being the biggest blocker. More on the topic is on Steve Souders' blog: http://www.stevesouders.com/blog/2008/12/27/coupling-async-scripts/ Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Wed, Apr 22, 2009 at 12:42 PM, Brion Vibber <brion(a)wikimedia.org>

wrote:

> On 4/22/09 9:33 AM, Sergey Chernyshev wrote: > > >> Exactly because this is the kind of requests we're going to get, I >>

think

it > makes sense not to have any library bundled by default, but have a > centralized handling for libraries, e.g. one extension asks for latest > jQuery and latest YUI and MW loads them, another extension asks for > > jQuery > only and so on. > > Considering we want core code to be able to use jQuery, I think the case for bundling it is pretty strong. :) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Reply