So something like: new Element('img', { src: new URI.GoogleChart
(...) });
Interesting. You don't need it to extend string to do that though. But
it does open up some interesting extension possiblities.
My issue with that is that it would violate the Liskov substitution
principle of object oriented design. The subclass would have a
stronger contract than the superclass. Introducing this anti-pattern
could open up a can of worms.
We should probably point out that at this point this discussion is
more about the introduction of various design patterns to MooTools
rather than just the URI class itself.
While we're on the subject, it might be a good idea to make the URI
implementation immutable. This is would avoid issues like this:
var SomeClass = new Class({
initialize: function(uri){
this.uri = uri;
},
goToRoot: function(){
someiframe.location = this.uri.setFilename('');
},
goToIndex: function(){
someiframe.location = this.uri.setFilename('index.html');
}
});
a = new Object();
a.uri = new URI(...);
b = new SomeClass(a.uri);
b.goToIndex();
a.uri has now unexpectedly changed.
Color, String, Number, Function and the others are already very wisely
immutable.
Date is unfortunately already mutable in JavaScript but I would've
wished for it to be immutable.
On 15 Mar, 01:24, Guillermo Rauch <[email protected]> wrote:
> I disagree. I want URI to be abstract, to produce strings and be extensible.
> One of its uses is altering the window location, but it's not the only one.
> I'm eager to implement this:http://www.maxb.net/scripts/jgcharts/include/demo/
>
> by extending URL. So let's make it happen.
>
> On Sat, Mar 14, 2009 at 1:59 PM, Sebastian Markbåge
> <[email protected]>wrote:
>
>
>
>
>
> > One thing we haven't talked about is how this is going to change in
> > the newer browsers that implements HTML 5.
>
> > The working draft defines "The Location Interface":
> >http://dev.w3.org/html5/spec/Overview.html#the-location-interface
>
> > IE 8 has already implemented it and can be extended from
> > window.Location.prototype:
> >http://msdn.microsoft.com/en-us/library/dd347128(VS.85).aspx
>
> > So I would say that the current URI/URL should instead be a new native
> > called Location and inherit the legacy window.Location. This can then
> > be used for URL related manipulation.
>
> > I know that you're skeptical about including HTML 5 drafts this early
> > but since a lot of work will probably be based on what's in MooTools
> > More it's probably a good idea to go for that naming convention
> > already.
>
> > Then we can have an alternative extensible URI class for multiple
> > schemes that may or may not be locations.
>
> > On 13 Mar, 05:13, Thomas Aylott / subtleGradient
> > <[email protected]> wrote:
> > > You make a good point.
> > > I was actually dealing with some urls today that were really annoying.
>
> > > I had to check the platform and redirect to a different page. That
> > > should be pretty easy, but isn't.
>
> > > Give me something that I can use with window.location or a .go() method
> > > (of whatever name) and I'm sold. I don't care if it extends string or
> > > not. Ideally I wouldn't like the idea of it constantly reparsing a
> > > string, but it doesn't really matter to me from an end-user perspective.
>
> > > var url = new URL();
> > > // defaults to window.location
>
> > > if (mac) url.set('basename', defaultBasename + '-mac').go();
> > > // whatever means the bit at the end of the "path" before the extension
> > > if (win) url.set('filename', '').go(); // EG:
> > > mydomain.com/dir/index.html -> mydomain.com/dir/
>
> > > Anoyone who can give me something to this effect without forcing me to
> > > deal with slashes and file extensions wins a thumbs-up.
> > > I don't care about method names or subclassing or whatever. Just give me
> > > the goods! :D
>
> > > — Thomas Aylott / SubtleGradient.com
>
> > > Sebastian Markbåge wrote:
> > > > To me, the purpose of a URI class is so that we DON'T
> > > > have to deal with string manipulation.
>
> > > > Aaron, could you perhaps fill me in on a few concrete URI manipulation
> > > > scenarios where it would be more beneficial to have string
> > > > functionality?
>
> > > > On Mar 12, 8:06 pm, Thomas Aylott / subtleGradient
> > > > <[email protected]> wrote:
>
> > > >> I think this is best.
> > > >> Let's rename URI -> URL (or even String.URL ideally) and we can spend
> > > >> some time doing a "proper" URI class also.
>
> > > >> — Thomas Aylott / SubtleGradient.com
>
> --
> Guillermo Rauchhttp://devthought.com
