I'm inclined to keep our URI script as it is so that it extends the string but the object returned is still a string. However, I like some of the functionality in your class. I'd be very open to adding new methods to ours that allows you to parse URIs that have things like usernames and javascript: as well as a toRelative/Absolute kind of method. Would you be interested in contributing to these changes? If not, it'll have to wait until we can incorporate these concepts.
On Tue, Mar 10, 2009 at 8:27 AM, Guillermo Rauch (via Nabble) < [email protected]<ml-user%[email protected]> > wrote: > MooTools More RC1 (released yesterday) ships with a URI component which is > a subclass of String. > An important advantage of that approach is that extends the String native. > This means you can take advantage of all the string methods directly applied > to your URI object, or send an URI instance to methods that expect strings > > What I like about your script is the extensible nature of the schemes. Even > though most schemes can be perfectly tackled by the More RC1 URI Regexp, > javascript: is a counter-example which it couldn't possible support. Plus > the API is designed for a fixed set of URI components, which if you take a > look at the > schemes<http://en.wikipedia.org/wiki/URI_scheme#Official_IANA-registered_schemes> > is > not a reality. > > Our current URI is more URL than URI. > > -- > Guillermo Rauch > http://devthought.com > > > ------------------------------ > View message @ http://n2.nabble.com/Uri-class-tp2456119p2456224.html > To start a new topic under MooTools Users, email > [email protected]<ml-node%[email protected]> > To unsubscribe from MooTools Users, click here< (link removed) >. > > > ----- The MooTools Tutorial: http://www.mootorial.com www.mootorial.com Clientcide: http://www.clientcide.com www.clientcide.com -- View this message in context: http://n2.nabble.com/Uri-class-tp2456119p2456472.html Sent from the MooTools Users mailing list archive at Nabble.com.
