Last modified: 2011-11-17 22:04:04 UTC
Michael Dale has argued me into thinking that the following things about this class are overkill. - Breaking down userinfo into user & password. Our primary use case is HTTP and URI passwords are actually illegal there anyway. Removing this will save several internal methods and tests when serializing the URI. - The uri.clone() method, which is just sugar for another new() call - having its own encode function -- there is such a function already in mediawiki.util.js, called rawurlencode , should standardize on that. - should investigate whether jQuery.param() can replace the path serialization code (not sure if we can do that and also have the slightly custom encoding & decoding that mediawiki seems to like). Arguably this bug is a request for "de-enhancement". But we need more people who think like that ;)
Re: rawurlencode: Had a look at mediawiki.util.js -- it's got a lot of miscellaneous stuff and the dependencies pull in a lot of other jQuery modules. There are three methods which are URI-related - rawurlencode - wikiurlencode - getParamValue Seems to me that the right thing is actually to: - move mw.Uri.js to be a new module, mediaWiki.uri.js, ideally no dependencies - refactor rawurlencode, and a few other such methods, into mediaWiki.Uri.js. - refactor/rethink getParamValue, it is way better to do mw.Uri( currentUrl ).query[ 'name' ] Also see bug #27730 which was discussing yet another method for url manipulation
I would add that it would be nice if mw.Uri more gracefully handles relative urls
@mdale - an example? You mean URLs with '..' in the path or URLs which are just paths, no protocol or host??
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
Fixed, and it handles relative urls too now.
