Last modified: 2012-06-20 04:55:23 UTC
Resource loader should allow to join main script with it's extensions to avoid race conditions when loading scripts in parallel (Firefox above 5/Chrome when scripts load in body). Would also be nice to optionally minimize them. Something like that would work: http://pl.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&titles[]=User:Nux/wp_sk.js&titles[]=User:Malarz_pl/wp_sk.js&titles[]=User:ToSter/wpsk_user.js Order needs to be preserved. BTW race condition occurs because of bug 27488.
When such scripts are made into modules through the new Gadgets extension, this'll automatically happen. RL doesn't need hacks or workarounds for loading wiki pages, the wiki pages need to become modules. We've already solved these problems for modules, no need to solve them again for wiki pages.
Provisionally adding dep on the RL2 tracking bug -- Roan is that appropriate or should this be closed out / merged with something?
Not all scripts are gadgets. Also note that some scripts have extensions which is the case. Not all users of scripts use all extensions. It's not possible to create gadgets with all possible combinations.
(In reply to comment #3) > Not all scripts are gadgets. Also note that some scripts have extensions which > is the case. Not all users of scripts use all extensions. It's not possible to > create gadgets with all possible combinations. Ideally, extensions are separate modules. Also, ideally, it should be possible to make modules out of user scripts without having them be gadgets. That's probably something we should be working on next. CC Krinkle for thoughts.
Do note, that some script (and especially script extension creators) are admins so they create scripts in their own namespace (user namespace). Anyway... Would you accept a patch for a quick fix like "titles[]" param mentioned above? This is a now-problem so I would like to have a solution in a foreseeable feature.
That makes sense for a remote gadgets too. Instead of four mw.loader.load invocations there can be one (or two - depending on how styles are going to be supported), when loading gadgets from another wiki (for example: [[pl:s:MediaWiki:Gadget-searchbox.js]]). Nux, as a workaround for now, you can turn the main script into a ResourceLoader compatibile gadget (or just a small part of it, which provides a thin interface for extensions) and then use in extensions the following code: mw.loader.using( "ext.gadget.awesome", function() { // Register extension here } ); This will automagically load the main script and after the script is loaded, the callback will be executed.
(In reply to comment #6) > That makes sense for a remote gadgets too. Instead of four mw.loader.load > invocations there can be one (or two - depending on how styles are going to be > supported), when loading gadgets from another wiki (for example: > [[pl:s:MediaWiki:Gadget-searchbox.js]]). > Loading Gadgets from a remote wiki is a solved problem in the RL2 branch. mw.loader.load( 'gadget.foobar' ) (or mw.loader.using for that matter) will Just Work and will know which modules to load from which domain. > Nux, as a workaround for now, you can turn the main script into a > ResourceLoader compatibile gadget (or just a small part of it, which provides a > thin interface for extensions) and then use in extensions the following code: > > mw.loader.using( "ext.gadget.awesome", function() { > // Register extension here > } ); > > This will automagically load the main script and after the script is loaded, > the callback will be executed. Yes, if you're an admin you can do this. If you're not an admin, you're screwed. That's a problem.
(In reply to comment #5) > Do note, that some script (and especially script extension creators) are admins > so they create scripts in their own namespace (user namespace). > Yes, not everyone has the ability to create gadgets, so gadgets aren't the answer for everyone. This is a problem and I want to fix it at some point. > Anyway... Would you accept a patch for a quick fix like "titles[]" param > mentioned above? This is a now-problem so I would like to have a solution in a > foreseeable feature. My concern is that any quick fix for a now-problem will have to be supported indefinitely into the future. That said, if the proposed patch is generic (i.e. allows concatenation of arbitrary wiki pages, not just JS pages), it wouldn't be that much of a burden to support from here on out, and it should be fine. Also, I would prefer &titles=Foo|Bar|Baz over &titles[]=Foo&titles[]=Bar&titles[]=Baz because the former is an established convention for api.php. Note that | is not a legal title character so it's safe to use as a separator. So yes, patches are welcome :)
Sorry, for the delays - was busy on other ends... Anyway this seems to be harder then I thought it would be. What I was not aware is that all action classes assume an action occurs for one and only one page. Changing that behavior would probably break everything which is not what I'm willing to do ;-). Anyway. You mentioned that you'd like it to join arbitrary pages not just JS pages so I'm assuming you don't want it in Resource loader. So do you think this should be an api module, special page (in an extension?) or did you had something else in mind?
Marking this as INVALID. RawAction is intended for loading the raw code of a WikiPage. Optionally the response can be given a custom Content-Type (e.g. for raw css or javascript loading). This type of loading is discouraged. Another old feature is the ability for users to store and execute some javascript code from a fixed subpage name of their User page (User:Name/common.js and User:Name/<skin>.js). The loading of other sub pages is not a feature, but an undocumented hack (still to date, not documented in the software). Whether documented or not, that ability is pure javascript (adding a <script> tag to another action=raw url) and not related to MediaWiki in any way. As such "user scripts" (other than /common.js and /<skin>.js) technically don't exist and therefore can not be improved because they are not recognized by the software. The only way to improve their handling is by creating a feature that recognizes these pages and deals with them. And... that's exactly what Gadgets and ResourceLoader does. Note: * Last year the basics of ResourceLoader have been brought to site scripts and to Gadgets. Gadgets can now make use of ResourceLoader optimization. * Later this year (if all goes well), all of ResourceLoader and more will be brought to Gadgets, this will be released as Gadgets 2.0 * The next step is to extend Gadgets to have a user space (effectively introducing the concept of "user scripts" as an actual feature for the first time, because the currently used method is not a MediaWiki feature but pure javascript). This is currently just an idea, but if all goes well this will be started in 2013 as Gadgets 3.0. - bug 34958.
