https://bugzilla.wikimedia.org/show_bug.cgi?id=33746
--- Comment #12 from Krinkle <[email protected]> 2012-01-21 00:37:43 UTC --- (In reply to comment #11) > (In reply to comment #10) > > > > I doubt that. There has never been an automatic dependency on anything. > > That's because we never had ResourceLoader before. Exactly. Before ResourceLoader, mw.util didn't exist. When it came into existence people should have known that it required declaring a dependency. In "most" cases this was done, but the people that forgot or didn't know about it likely didn't see any problem because another module happened to cover for them, in time. Basically I mean that with ResourceLoader came dependencies, not in two stages, but as one thing. Again, I'm not blaming anyone for forgetting that, but that is how it is. > I made a comment to that bug (bug 29384) just today. I think we can close that > now we know what casues it. Yep, done. Thanks. > > > Sure it could be added as a dependency. And we probably should since so many > > users forgot to do it, but this is a very bad habbit to go into. I'd rather > > avoid it. > > Note that my suggestion would only apply to > MediaWiki:Common.js/User:common.js, > *because* it is the only module that has no mechanism for declaring > dependancies .. > > > I think its safe to say that there are no high usage site scripts or gadgets > > currently in production missing dependencies or document-ready hooks, > > otherwise > > we would've had complaints already as that code is technically broken as it > > is. > > I doubt that. There are plenty of gadgets on enwiki that use ResourceLoader > without declaring there dependencies. With declaring those becoming mandatory, > that is when we will see the most problem. And I do agree they need to be > declared. But that is easy to fix. My only beef remains common.js. We've discussed this on IRC in the mean time. Declaring dependencies was never optional and this system has not changed in 1.19 or 1.18, since it's introduction with ResourceLoader 1.0 in MediaWiki 1.17. So whatever gadget has been migrated to use ResourceLoader modules should have including declaring dependencies in that migration, that's simply part of the proces, just as important as anything else. Basically all 1.19 does is load javascript faster, making it more likely that code that uses a module but doesn't declare it as a dependency fail. Which is a unfortunately more common that it should be (it shouldn't exist at all), but in the end it's a downstream/user problem. I believe we can get this easily fixed before deployment of 1.19 so let's try that first. It's just adding of dependency declarations in the registry. > If we aren't going to pre-declare mediawiki.util for common.js, I still like > to > know if wrapping the entire file is absolutely necessary? No, not per se. Code that uses code from another module needs to be declared in such a way that it will be executed after that other module is loaded. In a scenario where no module registry is available this means using mw.loader.using()'s "success"-callback. You can wrap part of a script or all of it, doesn't matter. > [..] Is mw.loader.using() asynchronous or synchronous. Both mw.loader.load and mw.loader.using are asynchronous. So: > mw.log('foo') > mw.loader.using( 'module-x', function () { > // module-x is loaded and ready for use > mw.log('quux') > }); > mw.log('bar') Will, assuming module-x hasn't been loaded yet, result in "foo" > "bar" > "quux". > The documentation [of mw.loader.using] says to use "two or three > parameter", but the source reveals that both callback parameters are optional. Yes, it says to use two or three, because using no callback at all is quite a pointless use of mw.loader.using; If you're not using the module inside code, why use using()... > So would simply putting the line "mw.loader.using('some.module');" not be > adequate? If not, would it be hard to make .using synchronous and make it > simply use return(); on completion if no callback is passed? No, it's either impossible or "bad" use of javascript. The asynchronous nature and event-driven flow is what allows things to happen the way they do. It makes no sense to block javascript execution because in one script there is a dependency on something and it loads the module on the first line. If you've got a bunch of code that depends on one or more modules the solution is to request those modules to be loaded (asynchronously, allowing other scripts to do their thing in the mean time) and while that is request is running the callback is remembered, and as soon as the module request is done it'll come back to that function and execute it. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
