2010/9/7 Platonides <platoni...@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)
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
