Last modified: 2014-08-27 16:15:46 UTC
Just like the backend, the front-end should be less tied into MediaWiki base as well. It sounds more complicated than it really is though. All we need to do is move mw.loader into a separate file and create an instance of it in mw.loader. It's already an object constructor, except that right now it is instantly-instantiating an anonymous object constructor (this.loader = new (function(){ ... }));
Setting status to NEW. Not a priority right now.
Issues: * Loader uses mw.log, mw.html, mw.messages, mw.config (skin, wgUserLanguage, debug, wgResourceLoaderMaxQueryLength)
mw.html.escape is easily re-created. The ResourceLoader object constructor would take an option object: mw.loader = new ResourceLoader({ log: mw.log, msgStore = mw.messages.values .. }); Last year that sounded do-able, but today we also have custom load sources and callback queue. So it gets a little more complicates. Though using $.Callbacks() might make some of that easier (if we want to depend on jQuery for the core loader framework).
Both in the design and implementation we've done pretty well in keeping ResourceLoader independent from MediaWiki, but it has been integrated a little bit here and there. I hope to have some time next quarter to separate the last bits out and move it to its own project with a documented API and release/version policy.
