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 <md...@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 <br...@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 > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
