Last modified: 2012-03-02 00:38:55 UTC
the problem: Gadgets are loaded before all core objects are initialized. Reproduction: create a gadget that uses "mw.user.name()" result: javascript error "object does not have a method "name()" ". core mw objects should all be fully initialized before any "user code" (i.e., site common.js, user common.js and all gadgets) are run, otherwise it's useless. if i need to test in the gadget code whether or not the "mw" object exists, or whether it contains a field named "user", or whether this field has a method "name()", then i can't use it.
(In reply to comment #0) Have you added the module "'mediawiki.user" as a dependency for that gadget, on MediaWiki:Gadgets-definition? See * [[ResourceLoader/Migration guide (users)#Migrating user scripts]] * [[ResourceLoader/Default modules]] for more info.
(In reply to comment #1) > See > * [[ResourceLoader/Migration guide (users)#Migrating user scripts]] > * [[ResourceLoader/Default modules]] > for more info. Uops... broken links. They should be: * [[mw:ResourceLoader/Migration guide (users)#Migrating user scripts]] * [[mw:ResourceLoader/Default modules]] * [[mw:Extension:Gadgets#Options]] Here is an example of a gadget which has "mediawiki.user" as a dependency: https://commons.wikimedia.org/w/index.php?title=MediaWiki%3AGadgets-definition&diff=67522390&oldid=67424974
thanks for the pointer - will do that. i still think that it makes little sense to require adding dependencies on core functions as in "mw.user", "mw.options" etc. it can also creates problems for things in site common.js, and personal common.js. these do not have the dependency mechanism, so they are left with the need to package parts of themselves in "mw.loader.using()", just in order to gain access to username. most people will take the easy way out and will revert to using wgUserName - exactly the opposite of what we want to happen. to summarize: i still think it's a bug, even though the dependency mechanism offers a solution for gadgets, IMO this solution is a "bug workaround" rather than a legit answer, and it does not provide solutions for site common.js and personal common.js peace.
thanks for the pointer - will do that. i still think that it makes little sense to require adding dependencies on core functions as in "mw.user", "mw.options" etc. it can also creates problems for things in site common.js, and personal common.js. these do not have the dependency mechanism, so they are left with the need to package parts of themselves in "mw.loader.using()", just in order to gain access to username. most people will take the easy way out and will revert to using wgUserName - exactly the opposite of what we want to happen. to summarize: i still think it's a bug, even though the dependency mechanism offers a solution for gadgets, IMO this solution is a "bug workaround" rather than a legit answer, and it does not provide solutions for site common.js and personal common.js peace. (In reply to comment #1) > (In reply to comment #0) > > Have you added the module "'mediawiki.user" as a dependency for that gadget, on > MediaWiki:Gadgets-definition? > > See > * [[ResourceLoader/Migration guide (users)#Migrating user scripts]] > * [[ResourceLoader/Default modules]] > for more info. upon reading, it actually lists mw.user as one of the "default modules", which i read as "modules which are always available". the problem is that "mw.user" exists, but parts of the functionality (specifically, "mw.user.name()") are still missing when the gadgets run, so on further examination - definitely a bug. peace.
'mediaWiki' is an extensible object just like 'jQuery'. Not everything in the 'mediawiki' object is a module that is always available throughout the entire load flow. [[mw:ResourceLoader/Default modules]] is a list of modules *available* by default in a MediaWiki install. These aren't all loaded by default (there is no point in loading modules that are never used, there are a loot of modules). Hence the existence dependency system. Every module declares what it needs and the loader will make sure that everything is loaded as fast as possible, and executing it as soon as anything it needs is loaded as well. 'mediawiki.user' is a module (creates the mediaWiki.user object), as is 'user.options' (populates the Map in mw.user.options). So all modules are available by default (available to load on-demand as you need them), this doesn't mean the same as 'loaded by default'. Marking INVALID as such, this is a misunderstanding of terminology.
