Last modified: 2014-11-17 10:35:50 UTC
Today you only can load modules that are specified by MediaWiki, e.g. jQuery extensions, RL-Gadgets and mediawiki-utilities (legacies), and static uris with the ressource loader. I already thought about registering user-script-modules, e.g. last lines of http://de.wikipedia.org/wiki/Benutzer:✓/js/deSecure.js. Here other scripts can use the mw.loader.using method, I chose "user.<usernick>.<scriptname>" for the module name analogous to "ext.<extensionname>", "jquery.<modulename>" etc. You already can use the mw.loader.register method to set dependencies, load some system messages per api, specifiy css (or load from api) and design a to-be-executed function, and then mw.loader.implement() them to your module. But this needs up to 3 file loads (script file with function, dependencies and implementation; messages api; css file) and is used by a call of mw.loader.load(<static url of script file>). Also the dependencies don't work as you use other user scripts, which would cause a request ending up in state:missing when they're not loaded then and preventing the real implentation by that. A better way would be loading them one-in-all (and not module by module, see Bug 26291), just by one simple module request that specifies project (+project language), user, module name and i18n (message language, by default uselang). Of course for detecting every modules' messages and dependencies either a auxiliary page (like in the Gadget extension) or a preprocessing of the script page would be needed. I'd propose the latter, this could be done like a /* comment */ at the top of the page where the module creator can specify dependencies, messages and CSS-pages to be embedded in one call of loader.implement. The function would be either a also spezified one or the rest of the script.
Bugzilla is configured in a stupid way that makes me put a comment here; it won't let me mark this as a duplicate otherwise. *** This bug has been marked as a duplicate of bug 25845 ***
I knew that bug already, but it seems to request the provision of a non-uri-load function (aokomoriuta in c9: "It's just to make a helper method"). My proposal is about a feature in load.php to deliver a definable set of user pages together as one module. Michael Dale had similiar intentions (c5, c8): "The important part is they have a way to transition [user scripts] into normal named modules" "support a simple interface or SpecialPage for defining what page resources ( and associated messages / dependencies for thous resources ) are globally used on a given wiki, this way their versions numbers can be included in the start-up module definitions" I think a separate bug should be filed for this issue.
Changing the scope of the bug a bit. Right now RL loads wiki pages in two places: Site-scripts (MediaWiki:Common/skinname.js/css) and user-scripts(User:Name/common/skinname.js/css). We should simply make this into public functionality rather than internally for those two modules: /* Example */ ['ext.Something'] = array( 'scripts' => 'resources/something/something.else.js', 'styles' => 'resources/something/something.else.css', 'wikistyles' => 'MediaWiki:Something-customize.css', // <!-- from the wiki 'wikiscripts' => 'MediaWiki:Something-customize.js', // <!-- from the wiki 'dependencies' => 'jquery.ui.dialog', 'messages' => array( 'something-title' , 'something-options' ). ); That way those would simply be included in the same http request and minified/combined (just like site/user scripts are now)
I think we have to avoid loading CSS per RL, because there are still clients out there with no / too old / disabled javascript. The only case for allowing this is when the CSS-pieces are needed (only) for and request by some scripts (gadget or user script). Any modules which contain script-independent CSS (site, user, css-only-gadgets) should be requested by a static link-tag in the documents head.
Marking invalid. See also: * (bug 27561) Register modules client side * (bug 25845) Support loading wiki pages through mediaWiki.loader.load() - creating/loading a wikimodule on the server side has also implemented (don't know the exact bug id) - loading wiki modules via .php is also possible, to do this one has to add [ResourceLoader] to it's gadget definition. - Loading one ore more raw wiki pages as js/css resources through load.php (without them being an actual module) is likely to be implemented as part of bug 25845.
