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&oldid=26818359#New_interface_feature * * 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
