Last modified: 2013-10-31 01:04:29 UTC
mediawiki.util should separate methods that do mediaWiki "page" stuff vs classes that do "utility" stuff. This way extensions that have alternate page structure or "skinless" entry points like "iframe video player", "facebook connect" type popup or any "popup windows" don't have to load DOM targets and convience functions for stuff that does not exist. ( not to mention stand alone usage ;) Some culprits include: "mw.util.updateTooltipAccessKeys", "mw.util.$content", "mw.util.addPortletLink" "updateTooltipAccessKeys" etc. I suggest moving base skin helpers into mediawiki.skin and keeping mediawiki.util for utility functions.
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
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.
