https://bugzilla.wikimedia.org/show_bug.cgi?id=27488
Krinkle <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #36 from Krinkle <[email protected]> 2011-06-04 16:34:46 UTC --- The script you've linked to doesn't handle callback, dependancies or a combination between the two. Nor does it link styles to scripts (which is very important for extension modules, styles need to be applied first). The order in which modules are loaded in ResoureLoader is very predicatable. However the in order in which module requests complete or finish is unpredicatable. This isn't fixed in your script, nor do I think it should be fixed. The order doesn't matter in most cases. When it does, then a dependandy should be declared by the module-author (that way you don't have to load them in the correct order yourself). For example: Modules: * mw.special.foo * mw.ext.bar * mw.gadget.johnScript * mw.gadget.alexScript Suppose all of them are loaded, the http requests are going in an unknown order. If "Alex" is assuming (because he knows) that his script was added to the queue after John's script (and alexScript.js contains calls to functions from johnScript.js), then he may very well have a problem. Because, like you said, the order is unpredictable, and if alexScript.js would finish loading first (becuase it's small, whatever), it would fail in errors screaming alexScript.functionname undefined. Aside from that, John may at any point decide to add his script to the queue in a different way or at a different time. Resulting in Alex script breaking as well. The solution is ResourceLoader dependancies. With this system ResourceLoader will load all scripts from the server and these requests may run in parallel and finish in an uncontrolled order, it simply loads them as fast as possible and ignores the order (in many cases it'll roughly be the original order but not by definition so). The finish of a resourcerloader request is not per definition the start of the execution (which is contrary to a "normal" load with a script-tag, in which case the end of the request is instantly the start of the execution of the javascript code). The power is in the execution. Because of the system around the requests, ResourceLoader will capture the module's code and execute them in such an order that dependancies are handled well, styles are applied first, interface/localized messages are available and more. This framework is fairly lightweight and hardly slows down the page. The slow-down is either because the server is slow, or because the script is big, or maybe it appears to be slow because it's loaded at bottom of the page (in which the load itself may be fast but starts later than you would hope). The ultimate end of the loading procedure of resourcerloader, if I remember correctly, may very well be after the "document ready" event. This event is not postponed untill all "bottom load" scripts are finished (or atleast shouldn't be, if it is, please open a new bug report). If a piece of javascript needs to manipulate the page before it's shown to the user, but can't be executed in the top (because the page doesn't exist yet then), then you should register your module with "position" => "top", and wrap your script in jQuery(document).ready( function.... ); That way it'll be loaded on top but executed as soon as the document object model is ready. Since r85616 (and possibly related revisions) implemented the 'top' positition, which I think was the main goal of this report, I'm marking this as FIXED again. if you intended the scope of this bug to be bigger, please open seperate bugzilla tickets for seperate features/bugs. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
