Talk:ResourceLoader/Core modules/Archive

HTML and map modules

I mean e.g. this code:

var h = mw.html;
var loaderContainer = h.element( 'div', { id: 'ext-foobar-loader' },
	new h.Raw( h.element( 'img', {
		src: mw.config.get( 'stylepath' ) + '/common/images/ajax-loader.gif',
		title: 'Loading...'
		}
	) )
);
// loaderContainer is '<div id="ext-foobar-loader"><img src="/w/skins/common/images/ajax-loader.gif" title="Loading..."/></div>'

What does this suppose to help with? Maybe the example is bad, but this doesn't seem helpful at all. How is this easier then using innerHTML or even DOM methods? Or maybe it does something extra?

The Map module seems to be at least easier to use, but is it really worth the trouble? It doesn't seem store variables in cookies or localStorage then what is it every day scripter?

Regards, Nux 23:51, 13 February 2011 (UTC)

Hmmm...

The entire mw.html bit except possibly escape seems to be completely useless, mw.config doesn't appear to do anything at all, the mw.legacy object is empty, the mw.user object doesn't appear to have most of the properties listed here (and why would they be functions in the first place, exactly?), mw.util.$content is a jQuery bit without any particular reason for it to be, addOnloadHook is replaced with some odd, seemingly inefficient bit of jQuery... Am I missing something here? --Yair rand 07:23, 15 February 2011 (UTC)

(Looks at mw.loader.load source) Ummm... O_O --Yair rand 07:38, 15 February 2011 (UTC)

Where are you referring to with "doesn't have most properties". Doesn't have X where, on your wiki ? On Wikipedia ? On MediaWiki.org ? 1.17 is still in development so there may be different versions around. The documentation here describes exactly what the latest version can do, no more (sometimes less since documentation is written afterwards).

mediaWiki.legacy is empty because, as the deprecation overview explains, the legacy variables are currently deprecated but not quarantined. Right now we leave a clear window for users to update their scripts. The deprecated functions are at their original locations, for now. During this process we check if the given modern and more compatible replacements in the mw.* library cover all cases without regressions compared to the legacy functions. Once that is completed the functions will be quarantined in mw.legacy so that users who hadn't had the time to convert their scripts can map function calls to mw.legacy as a temporary stop-gap.

mediaWiki.loader.load is currently primarily focussed on the loading of (multiple) combined and minified resources including the automatic detection of dependancies etc. That's what it does best and does good. Loading external scripts (or internal ones by full url, like in debug mode) is possible but by no meeans awesome. This has been improved a bit in the trunk development but not yet deployed yet on Wikipedia.

the mw.html object is by no means useless, but if you don't need it, don't use it. Krinkle 11:27, 17 February 2011 (UTC)

Hm, I thought they were all using the same version. Enwiki, Enwiktionary, and Mediawiki.org all only have the options propery of mw.user, and don't have anonymous(), name(), or sessionId(). --Yair rand 11:41, 17 February 2011 (UTC)

$.post().complete is not a function

I tried to use .complete() in post but throws error. also i get error if i use $('').dialog() (not a bug in edit mode) ( i think i have to use if( $('#editform') ) ?). Sorry this is a cross posting from Wikipedia:Village_pump_(technical). Please help. -- Mahir78 08:37, 26 February 2011 (UTC)

Please post a more complete snippet, there's no way of knowing what's wrong with just this. Krinkle 21:01, 2 March 2011 (UTC)

textSelection not working outside edit screen

The jQuery.textSelection seems to be entirely unavailable except on the edit screen. (This is something I really wish I had known earlier...) Whatever the reason might have been for this, wouldn't it make sense to have this bit of information on the page, as well as listing other various jQuery bits that die as soon as the user goes onto a different type of page? --Yair rand 08:33, 4 April 2011 (UTC)

There are many modules available, what isn't needed by default is not loaded by default. If you need certain modules it is recommended you invoke your gadget or script like this (even if it's on an edit page, since for all we know it may be removed from the default-on-edit-pages), always declare the dependencies of your script (except for jQuery and the mediaWiki base object such as mw.config mw.util etc.):

window.MyTool = {
 init: function(){
   // something with $(..).textSelection
 }
};
mw.loader.using( 'jquery.textSelection', MyTool.init );

// or, if you need multiple modules:
mw.loader.using( ['jquery.textSelection', 'jquery.ui.tabs'], MyTool.init );

This will make sure jquery.textSelection is loaded before the code is executed. (either it's already loaded and immediately calls it, or it's loaded right away and then calls it) Krinkle 10:01, 7 April 2011 (UTC)

mediaWiki.util.wikiUrlencode

ISTM this method would be a lot more useful if it reliably returned the same encoding of the title as the parser uses in generating internal links. I have found at least two cases in which it doesn't:

1. The parser converts [[title]] to <a href="/w/index.php?title=Title" ...> if the wiki is configured to require uppercase titles, but wikiUrlencode("title") returns "title".
2. The parser converts [[It's All That]] to <a href="/w/index.php?title=It's_All_That" ...>, but wikiUrlencode("It's All That") returns "It%27s_All_That".

Are these bugs, or am I misunderstanding the purpose of this method? --R'n'B 20:48, 15 April 2011 (UTC)

mw.config.get function?

I don't understand why we use mw.config.get('wgVariable') instead of wgVariable. Is there some pros for using the method? Your answer is appreciated. Thank you. Kwj2772 14:37, 4 June 2011 (UTC)

If I understood correctly, the wgVariables are deprecated and will removed from global namespace. Using the get() method of mw.config will ensure the scripts still works when wgLegacyJavaScriptGlobals is set to false in the future. See also:

• rev:69472, where it is said that LEGACY_GLOBALS = true; "will not change until we are 100% ready to turn off legacy globals"
• rev:87856, which solves Bug 28916 by introducing the configuration variable wgLegacyJavaScriptGlobals. Such variable was described as follows:
  • Whether or not to assing configuration variables to the global window object. If this is set to false, old code using deprecated variables like " if ( window.wgRestrictionEdit ) ..." or " if ( wgIsArticle ) ..." will no longer work and needs to use mw.config instead. For example " if ( mw.config.exists('wgRestrictionEdit') )" or " if ( mw.config.get('wgIsArticle') )".

I don't know when they are planning to change wgLegacyJavaScriptGlobals to false, but I hope the information above helps you. Helder 14:10, 7 June 2011 (UTC)

@Kwj2772: I'm not sure wether you're asking to know why we've chosen to switch to mw.config or if you're asking why you should use it instead of the global "wgVariable". The latter is answered by Helder.wiki, I'll answer the former here.

We want to move to an object oriented approach for all our scripting, as well as make the javascript framework more robust and mobile. Up until fairly recently almost everything we were doing was occupying the global namespace of the javascript execution in browsers. Not just for primary components but even for very minor (sub)components. For example all the following as in the same, global, space:

MediaWiki stuff: wgPageName, wgCanonicalNamespace, clientPC, addOnloadHook, escapeQuotesHTML etc.

Browser native APIs: document, Math, location, history, navigator etc.

That's asking for trouble and increases likelihood of clashing variable names and/or very long names. It gets even more mixed up when using third party plugins. This doesn't scale in any way shape or form, so we've instead decided that any and all MediaWiki related methods and libraries should fall under the same tree, accessed via one global and one global only, "mediaWiki". And everything is nicely organized under there. So we've got mw.config, mw.html, mw.page etc. Krinkle (talk) 17:29, 27 February 2012 (UTC)

mw.util.$content undefined in Modern

I wonder why mw.util.$content seems to be empty in Modern skin; I looked at the current mediawiki.util.js and some older versions and they look fine. —AlexSm 18:31, 31 August 2011 (UTC)

This was fixed in rev:80786 which isn't live yet. Interesting enough I answered the very same question on de.wikipedia just an hour ago. --Schnark 07:54, 1 September 2011 (UTC)

Thank you. I did not realize live WMF version is still lagging behind so much. As I slowly migrate global JS code to jQuery / mw I guess our Modern skin users will have to "suffer" for uncertain period of time. I tried to correct this in Modern.js but it seems my attempts where either too early or too late. —AlexSm 18:00, 1 September 2011 (UTC)

Token for manipulating watchList, 1.18 and 1.19

So 1.18 introduces (or will introduce) the requirement to use a token in order to manipulate the watchList, i.e. to execute API calls with "action=watch".
but resourceLoader will introduce mw.user.tokens.get(); only in 1.19. (if i understand correctly the content page)
this seems like cruelty to animals: we have many user scripts that manipulate the watchList (ok, not that many, but still quite a few), and for them not to break in 1.18 we will have to execute this one extra API call with "action=query&prop=info" to obtain a token, and then, in 1.19, if we want our code to be less ugly (and also faster), we will have to replace these API calls with mw.user.tokens.get(). in light of this 1.18 change, i'd like to ask to propagate the mw.user.tokens.get(); call to 1.18, or just tell me "dont worry your little head - it's already there". thanks, peace - קיפודנחש 23:06, 22 September 2011 (UTC)

I did not notice this memo before.

As you may see below (.user.tokens), this has been introduced already in May 2011 and was available in 1.18 from the start.

Greetings --PerfektesChaos 08:28, 30 November 2011 (UTC)

user.tokens

Declared to be available in 1.19, but present in 1.18. (rev:88554, May 2011). Check please. Greetings --PerfektesChaos 13:07, 29 November 2011 (UTC)

I tried to test this (on huwiki), but mw.user.tokens.get("editToken") returns "null". :( Any explanation is welcome. Winston 11:07, 22 January 2012 (UTC)

Browser restart fixed the pb. Strange. 89.133.63.54 13:30, 22 January 2012 (UTC)

mw.log

Its a little unpredictable where mw.log (ResourceLoader/Default modules#mw.log) puts its output. Different browsers and extensions uses different logging facilities and that makes it difficult to describe to users how to find the logging information. I wonder if a solution would be to have a user preference for logging the messages to the page itself or to a console, setting the preference default to embedded in the page (footer) itself. For those debugging a lot it would be better to untick it and dump debug info to a console. If a user then visits the specially crafted debug url (http://www.mediawiki.org/wiki/ResourceLoader/Default_modules?debug=true) the page would dump the logged messages clearly for the users to see and it would be a lot easier to explain to them what to look for. Jeblad 04:50, 7 December 2011 (UTC)

mw.assert

I wonder if some of the usual functions for assertions should be enabled in addition to mw.log when the specially crafted debug url (http://www.mediawiki.org/wiki/ResourceLoader/Default_modules?debug=true) is used. That would make it a lot easier to include (and exclude) simple tests in the code itself. Especially when trying to communicate with end users this could be really useful. Note that this isn't full-blown unit testing, its about generating useful error reports on individual pages where someone has observed a problem. Jeblad 04:55, 7 December 2011 (UTC)

Debug mode

When forcing a debug mode by adding "debug=true" in the URL a little more modules/gadgets than necessary will start dumping debug info. I propose that if the right hand side can be recognized as a module name and/or the modules string used in the call to the loader then only this module or modules will be delivered in a debug mode, not every modules. This will limit the amount of debug info exposed to the end user when [s]he is asked to report back the results from specially crafted debug URLs. For example it should be possible to limit the debug info to the CodeEditor gadget by writing something like "debug=CodeEditor", whil a string like "debug=true" would get everything. I wonder if it also should be possible to set the level to further narrow the amount of infor reported.Jeblad 05:23, 7 December 2011 (UTC)