On 09/08/2010 11:25 AM, Roan Kattouw wrote:
It's defined on a MediaWiki: page, which is
accessed by the server to
generate the Gadgets tab in Special:Preferences. There is sufficient
server-side knowledge about gadgets to implement them as modules,
although I guess we might as well save ourselves the trouble and load
them as wiki pages,
We should have an admin global enabled 'gadgets' enable system ( with
support for turning it on per user group ie all users, admin users etc.
Each gadget should define something like:
MediaWiki:Gadget-loader-ImageAnnotator.js where it has the small bit
that is presently stored in free text in MediaWiki:Common.js ie:
/**** ImageAnnotator ******
* Globally enabled per
*
http://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&old…
*
* Maintainer: [[User:Lupo]]
****/
if (wgNamespaceNumber != -1 && wgAction && (wgAction == 'view' ||
wgAction == 'purge')) {
// Not on Special pages, and only if viewing the page
if (typeof (ImageAnnotator_disable) == 'undefined' ||
!ImageAnnotator_disable) {
// Don't even import it if it's disabled.
importScript ('MediaWiki:Gadget-ImageAnnotator.js');
}
}
Should go into the "gadget loader file" and of course instead of
importScript, some loader call that aggregates all the loader load calls
for a given page ready time. It should ideally also support some sort of
grouping strategy parameter. We should say something like packages that
are larger than 30k or used on a single page should not be grouped. As
to avoid mangled cache effects escalating into problematic scenarios.
As we briefly discussed, I agree with Trevor that if the script is small
and more or less widely used its fine to retransmit the same package in
different contexts to avoid extra requests on first visit.
But it should be noted that separating requests can result in ~less~
requests. ie imagine grouping vs separate request where page 1 uses
resource set A, B and page 2 uses resource set A, C then page 3 uses
A,B,C you still end up doing 3 requests across the 3 page views, except
with 'one request' strategy you resend A. The forth page that just uses
B, C you can pull those from cache and do zero requests, or resend B, C
if you always go with a 'single request'. Of course as you add more
permutations like page 5 that uses just A just B or just C it can get
ugly. Which is why we need to ~strongly recommend~ the less than 30K or
rarely used javascript grouping rules somehow.
The old resource loader had the concept of 'buckets' I believe the
present resource loader just has an option to 'not-group', which is fine
since 'buckets' could be conceptualized as 'meta modules sets' that are
'not-grouped'. Not sure whats conceptually more clear. IMHO buckets is a
bit more friendly to modular extension gadget development since any
module can say its part of a given group without modifying a master or
core manifest.
At any rate, we should make sure to promote either buckets or 'meta
module' option, or it could result in painful excessive retransmission
of grouped javascrpt code.
--michael