Last modified: 2014-11-17 10:36:47 UTC
See also bug 27535. Being able to register modules on the client side will make it easier for users to write custom scripts, for example: register( 'myUserScript', { 'wikiscripts': ['User:Krinkle/Calender.js', 'User:Krinkle/toolboxlinks.js'], 'wikistyles': 'User:Krinkle/Calender.css', 'dependencies': ['jquery.ui.datepicker'], 'messages': ['hist', 'talkpage', 'recentchanges', 'nstab-main'] }); mw.loader.load( 'myUserScript' ); .. would make 1 http request for all of that. Although this will make existing things easier it also opens up good possibilities regarding the localization of scripts. Right now it is either solved by keeping objects inside the scripts like: 'msg-clickhere' : { 'nl' : 'Klik hier', 'en': Click here' //etc. } Or an additional request to the API is made to action=query&meta=allmessages, which brings in the extra complexity if having to wait for that to finish (callback, fallback, errors).
I don't think the registering of myUserScript is useful like that. A user should just need to write mw.loader.load("user.w:de.<username>.<userscriptmodulename>"); into his mypage/<skin>.js. The one call should register the module and load a script which comes with all its parts (script, style, messages, dependencies). When the parts change (e.g. another message) not every user should have to update his userscript, just the module's creator would need to change the definition of the used parts. This definition may be an additional page (like a Gadget definition), a comment at the top of the script or an entry of a special page. Also a version could be specified, but we cant initialize RL with a whole list of user-module-versions. For that you'd need to activate a few modules at a (long) list in the preferences, then the few versions could be delivered. The returned script my look like the following: bla = {...} // initialising some variables: content of the requested scripts //auto-generated: mw.loader.implementuserscript("modulename", [dependencies], //as specified [css], //embedded from specified [messages], //expanded as specified function(){bla.do();} // a function to call when dependencies are met, must also be specified somewhere. ); Also we could embed the script pages into the module.script function, so we don't need to specify the function to call. Another implementation, like the mw.user.options, would be mw.loader.implementuserscript("modulename", [css], //embedded from specified [messages], //expanded as specified ); //autogenerated, does not execute anything, sets state to "loaded" //all the following is the content of the requested scripts: mw.loader.using( [dependencies], // inline-spzified function(){ //do something mw.loader.state("modulename", "ready"); //must be set from userscript });
In the ResourceLoader 2 project we will implement a very easy way for wiki users to create custom wikipage-modules from within the wiki. That way things will stay central and registration will be cached as well. Registering an actual module on the client side seems like a lot of work to implement and the ultimate goal (loading wiki pages through resourceloader) can be achieved much easier. By not letting users register modules on the client side and instead allowing them to load (a set of) pages directly, it will be easier for them as well. See also bug 25845. Marking this one as WONTFIX.
