source: https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/reso...

tests: https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/test...

Been meaning to make a Github repo for this. Any interest?

So the current behaviour is to turn "?&foo=bar&&foo=bar" into "?foo=bar". I've coded a few client-side scripts where removal of unneeded ampersands was useful, but at the same time I needed to keep both repeated name-value pairs (for more advanced form submissions).

I would suggest making normalizeSearch less destructive - i.e. only targeting the unused question mark and ampersands - and splitting the name-value pair deduplication into a separate method.

Liking the jQuery-style method chaining.

jQuery does use Method Chaining but it actually discourages the use of good JS OOP.

Cool work none the less, I didn't give you props in my original post.

Referring to the query as "search" makes no sense whatsoever.

[1] http://medialize.github.com/URI.js/docs.htm

for some more groaning, have a look at http://tantek.com/2011/238/b1/many-ways-slice-url-name-piece... ;)

Huh? Where?

and decomposed IDL - http://www.whatwg.org/specs/web-apps/current-work/multipage/...

  var temp = document.createElemenet('a');
  temp.href = 'http://www.google.com/search?q=foo#blah;
  alert(temp.hostname); // www.google.com
  alert(temp.hash);     // #blah
  alert(temp.protocol); // http:
  alert(temp.search);   // ?q=foo
  temp.search = '?q=baz';
  alert(temp.href);     // http://www.google.com/search?q=baz#blah

  // assuming this is running on http://www.example.com:
  temp.href = '/asdf.html';
  alert(temp.href);     // http://www.example.com/asdf.html

Does the IDL stuff work in non-browser Javascript (like node.js)?

URI.js could be really useful for developers building web apps that need to do a lot of URL parsing or manipulation. But developers who only need basic functionality outside of performance-critical loops would probably be better off using built-in functionality.

One of the things I found building up the PlaceSteal magical library was I needed an actual build/compilation step for turning the various external Javascript libraries I had in to one that would happily go through the Google compiler.

This included a whole bunch of hand-added patches for - for example - moving object-key specification in to one of dot notation or []notation. There were also a bunch of random patches to make things do what I wanted them to do, that didn't seem to be easily done via subclassing or poking around on the insides.

I'm pretty worried about the consequences when I have to upgrade one of the constituent libraries.

It's JSON powered similar to microjs.com (a great site, just not all inclusive) and I've still just got some work to go in terms of adding all the data I've got collected. If there's any interest, I could throw it up on Github and accept contributions to the data.

(One thing that may not be clear at this stage is that each lib will be tagged by license, dependencies, link to source code and/or documentation depending on availablility and have a short description)

Would love any general feedback too.

http://www.google.com/codesearch#epIciakqvFc/trunk/closure/g...

I have a bunch of functions (parse_params, get_host, etc.) across a number of projects and always find new bugs with weird URLs that are out in the wild.

parse_url http://us.php.net/parse_url for getting URI components

parse_str http://us.php.net/parse_str for getting query string variables

These two functions take care of the vast majority of my URI parsing/creation tasks.

Of course it would be nice to have a fluent interface like URI.js via a PHP class. And the URI normalization functions.

I was hoping there are some existing resources before I start porting this...

Please save me having to visit your repo by using accepted terminology if possible...