URI Proposal

[Garrett Smith]

On 9/9/07, zwetan <zwetan at gmail.com> wrote:

> when you see the gazillion libraries out there, either for Ajax,
> ActionScript, etc.
> the main common pattern you can see is that people stick to their libs,
> and do not agregate their findings in one unified library,
> so in the case of a URI class I could see 4 or 5 differents implementation
> made by 4 or 5 different group/people with 4 or 5 different API,
> which is not good.
>
> Sure, one could argue that the most used library would prevail after some time,
Remember BETA vs. VHS?

> but what about the cases where the X library got a better URI class
> than the Y library,
> but you still crave to use the String class of the Y library, but
> sadly URI being based
> on strings once you start to use the Y library you can not use the URI
> class of the X library, etc...
>
The current libraries suffer from worse problems. See the YUI
connection manager Prototype.js. The URI logic is inextricable. Users
get dependent on the libraries which are not namespaced (ES3) and
sometimes conflict by using the $ symbol top-level.

> No offense to Garrett, but I would not define a URI class this way at all,
> for ex using getProtocol/setProtocol function defined in the prototype
> make no sens to me, I would use a getter/setter and nothing would go
> defined in the prototype, just because I think its cleaner to access
> the property like that `myURI.protocol`.
>

We can take that a step further and define a QueryString class that
has a toString returning the raw queryString, toEncodedString,
returning the encoded queryString, and the parameter map functionality
defined in the current URI class.

var foo = aURI.query.getParam("foo");
if(foo == null) {
  aURI.query.addParameterMap( jsonArg );
};

This would be useful for other things, like POST data, for example.

If this were a wiki, you could edit the page directly or create your own.

You can copy-paste-edit my outline here. I suppose I could use my
JotSpot wiki page (Jot is another fine example of a bloated library in
action, though this has been and is being refactored by google's
experts. Hopefully it won't end up being garbage like google Groups.)

> My point is if each one of us go develop on their side an API, and
> also 4 or 5 other people/group
> do the same, in the end does ECMA will be able to say "we favour this
> one for this and that reasons" ?
> or does ECMA gonna say nothing and let people struggle with the same
> libraries problem that exists with ES3 ?
>

> zwetan
>


-- 
Programming is a collaborative art.