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:
- Normal script tags (current style)
- 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@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l