2010/9/7 Platonides Platonides@gmail.com:
Yes. If Common.js has issues for minimifying, gadgets could as well. I first thought at it as "legacy", but there might be some reason for wanting it loaded separately. As far as not providing any flag, minifyies it, that shouldn't be a problem.
It's likely that gadgets will have issues similar to Common.js's, yes, in which case it could be handy to still load them in legacy mode unless the gadgets definition page indicates it's RL-compatible. (That's another feature request: we should introduce that concept of legacy mode so we can combine scripts loaded in that mode rather than loading all of them separately.)
Maybe adding a gadget module which in turns loads the others as needed?
That could work, yes, but it'd mean the loader only finds out which gadgets it needs after the gadget module runs, which means it has to do an extra request back to the server to get them.
I'm not familiar with the resource loaded code to determine the best way to design it.
Basically the relevant facts are: * Module information is defined server-side and transfered to the client-side loader through either a standard mediaWiki.loader.register() call generated by the server or a custom registration script (called 'loader script' in the code) if defined * If server-side PHP code knows it needs a module, it can ask OutputPage to include it on a page. It does this by adding a call to mediaWiki.loader.load() * Near the bottom of the page (below everything but legacy-mode scripts, currently only site JS), mediaWiki.loader.go() is called. It consolidates all load() calls, resolves dependencies and obtains all required modules from the server in one request * Once these modules are loaded, their code is executed (in the correct order to satisfy dependencies) * On-demand loading after go() has happened can be done with mw.loader.using( 'modulename', function() { code using module } ); This will load the module and its dependencies, execute them, then execute the function provided to using().
This means that a gadget module that figures out which other modules to load could only use the on-demand mechanism: the other mechanisms are only available after the gadget module has been loaded. Using on-demand loading results in an additional request and should only be done when loading a relatively large portion of code that is only required upon a user action (e.g. jquery.ui.dialog when the user clicks one of the edit toolbar buttons associated with dialogs). Using on-demand loading for things that are immediately required on page load should be avoided if possible (and this usually is possible).
Unfortunately, I don't think these loader scripts currently allow you to override some but not all parts of the registration call, it's either all or nothing. This is particularly annoying since the last modified timestamp of a module is hard to obtain on the client side. Filed this as https://bugzilla.wikimedia.org/show_bug.cgi?id=25085 .
Roan Kattouw (Catrope)
And I don't understand what this last paragraph is about :) You are trying to reuse the same loader for all gadgets?
What I was saying is that when you use a custom registration script, that script is responsible for providing the loader with all the information it needs (module name, dependencies and last modified timestamp) without any help from the server (usually all of this information is defined on the server which then generates code to inform the loader). This is a problem, especially for the timestamp parameter, so I filed a bug requesting we make the information defined on the server side available to client-side custom loaders.
Roan Kattouw (Catrope)