mdale wrote:

Also I suggest moving the mediaWiki.user class outside of the core mediawiki.js since A) Its dependent on jquery.cookie ( which could be expressed as a normal resource dependency ) and B) its not needed for stand alone usage of the resource loader.

I'll create a mediaWiki.page or mediaWiki.wiki module soon and migrate the appropiate scripts to it.

On second thought, rather than moving mediaWiki-specific things out of mediaWiki.util, I think it is good where it is (they are "mediaWiki" utilities)

Instead anything not mediawiki-specific could go into a the convience functions plugin where $.trim, $.escapeRE etc. are
So mw.util.getParamValue would become $.getParamValue, and rawurlencode to $.rawurlencode.

And $content, addPortletLink etc. would stay in mw.util

mdale wrote:

These are functions that target mediawiki page interfaces. For example, How would these function be useful for an embed-player iframe page that just outputs a video player? ( In that context there are no portlet links etc. )... but the video player might want to escape some attributes or convert a title key into a link.

I think its worthwhile to distinguish utility functions related to the main mediawiki page interface vs utility function that could be useful across multiple mediawiki js use contexts / interfaces.

(In reply to comment #4)

These are functions that target mediawiki page interfaces. For example, How
would these function be useful for an embed-player iframe page that just
outputs a video player? ( In that context there are no portlet links etc. )...

I don't think that matters. That embed player would end up on a MediaWiki page eventually, right ? So it could need addPortletLink. Or when it builds an iframe, perhaps it builds a mediawiki-like list of links somewhere (ie. #p-myvideoplayer), then you can use this function for it as well.

Generally not needing a function in certain scenario is harmless. There are many classes, functions and variables in MediaWiki core not needed on most pages but they're initialised anyway since there's no way of knowing what is 'needed'. I know one case doesn't always justify another, but take GlobalFunctions for example. Many useful functions there but not needed on every page in every scenario.

but the video player might want to escape some attributes or convert a title
key into a link.

Escaping attributes is done in mw.html though.

I think its worthwhile to distinguish utility functions related to the main
mediawiki page interface vs utility function that could be useful across
multiple mediawiki js use contexts / interfaces.

I think it makes more sense to be distinguishing between "within MediaWiki" and "re-using outside MediaWiki" scenarios rather than "on MediaWiki articles" and "MediaWiki extensions iframe".

The functions are there, if you don't need them there that's fine. They're cached anyway. If you'd seperate modules like that, that means different resource requests and less cache use.

Then the client needs to re-download all functions because in that iframe the resourceloader link would not request "mediawiki.articleutils" module or whatever.

(bug 27149 refers to this bug)

Moved out part of them in r90605.

@Krinkle, this is one of the oldest tasks assigned to someone. Are you planning to work on it, and is its current priority correct?