When you use sub-classes, I agree. But when you use new Uri
('unkownscheme:unknowndata') or URI.create('unknown://...') I think it
should fallback somehow to a default unknown full URI.
There are situations where this is useful. For example relative link
parsing:
anchor.set('href', new Uri('unknown:path').toAbsolute());
// href equals 'unknown:path'
anchor.set('href', new Uri('http://mycurrentdomain.com/
someotherpath').toAbsolute());
// href equals '/someotherpath'
anchor.set('href', new Uri('http://someotherdomain.com/
someotherpath').toAbsolute());
// href equals 'http://someotherdomain/someotherpath'
In this case unknown URI schemes are still valid. It just falls back
to using the full HREF.
It's also easy to handle full URIs (known or unknown schemes) and
relative URIs without error checking:
myobj.fullURI = new Uri('http://mycurrentdomain.com/mybasepath',
relativeOrFullKnownOrUnknownUri).toString();
On Mar 11, 1:27 pm, Guillermo Rauch <[email protected]> wrote:
> I think validation should be transparent. For example, new Email('bademail')
> just fails to initialize and returns false.
> On Wed, Mar 11, 2009 at 9:49 AM, Sebastian Markbåge
> <[email protected]>wrote:
>
>
>
>
>
> > Ah, yes, sorry. I didn't mean to suggest that you didn't. I just
> > wanted to discuss the syntax since I'm unsure about it. Same as with
> > HTML. Where to put a ValidateHTML() function?
>
> > On Mar 11, 12:24 pm, Guillermo Rauch <[email protected]> wrote:
> > > I know it doesn't use try{}catch{} blocks, and I don't encourage it for
> > this
> > > component, it was just a fast way to put it into an example.
>
> > > On Wed, Mar 11, 2009 at 9:21 AM, Sebastian Markbåge
> > > <[email protected]>wrote:
>
> > > > In a way I like the idea of sub-classing because it's cleaner and more
> > > > consistent with how most of MooTools is designed. Although there are
> > > > several places where the pattern is to extend properties or hashes
> > > > (Element, Event, $).
>
> > > > Is the sub-class the same as the URI scheme or a new classification
> > > > though? For example: http:, https:, file:, webcal:, mms:, ldap:,
> > > > news:, svn:, git: are really different schemes with possibly different
> > > > extensions and meaning. Some are a superset or subset of these
> > > > schemes. Some share protocol. Some follow different schemes but would
> > > > still be considered a "locator" and hence a URL. So URI.URL would
> > > > still need to be able to be extended with various schemes.
>
> > > > If we introduce classifications such as "URL" and "Email" there could
> > > > also be the issue of what happens if a scheme belongs to both. I don't
> > > > really have an example so it could be an edge case. Possibly the im
> > > > scheme and tel/skype style phone URIs.
>
> > > > About validation... In my variant I utilized the regexps for a pattern
> > > > like this: Uri.validate('any known uri scheme'); OR Uri.validate.mailto
> > > > ('mailto:m...@email?subject=test');
> > > > MooTools doesn't really use throws or try-catches anywhere and IMO
> > > > it's with good reason. You could also do URI.URL.validate('any known
> > > > URL scheme');
>
> > > > However, Uri.validate.mailto() would still only validate a mailto: URI
> > > > and not an actual e-mail per say. Even Uri.validate.mailto('mailto:' +
> > > > email); would still consider 'm...@email?subject=test' valid. But this
> > > > is a particular edge case with e-mails. Either way, I don't think e-
> > > > mail validation belongs in the URI class since the URI is really a
> > > > superset scheme of e-mail addresses.
>
> > > > On Mar 11, 5:08 am, Guillermo Rauch <[email protected]> wrote:
> > > > > As you said, if let's say concatenation works flawlessly with a Class
> > as
> > > > it
> > > > > does with String, I don't see any other reason to subclass String.As
> > far
> > > > as
> > > > > the class design goes, I would like an approach like:
>
> > > > > URI = Base, abstract class.
> > > > > URI.URL = extends URI for the URL scheme
> > > > > URI.Email = extends URI for the email scheme
>
> > > > > and user can also extend it for the scheme he deals with.
>
> > > > > Since the API changes for each scheme (the name of the parts that you
> > can
> > > > > get), I don't see the point of having all the logic into URI. It's
> > not
> > > > like
> > > > > the method get('username') will work for all schemes, hence why it's
> > a
> > > > good
> > > > > idea to inherit from URI.
>
> > > > > Also, from FormValidator we could do something like:
>
> > > > > try {
> > > > > new Email(email_value);} catch(e){
>
> > > > > this.error('wrong email');
>
> > > > > }
>
> > > > > In any case, we can also use URI as a factory to create instances for
> > a
> > > > > scheme
>
> > > > > URI.create('http://', 'url');
> > > > > URI.create('http://', 'email');
>
> > > > > On Wed, Mar 11, 2009 at 1:59 AM, Thomas Aylott <
> > > > [email protected]
>
> > > > > > wrote:
>
> > > > > > The biggest issue is consistency.
> > > > > > Nothing else in MooTools subclasses String.
> > > > > > This is More and not Core, so the rules aren't as hard and fast.
> > > > > > But I don't think I want to recommend that people subclass string.
>
> > > > > > It all boils down to who is going to write all the specs and
> > maintain
> > > > this
> > > > > > thing into the future.
> > > > > > I'm not going to, so I don't get a real vote.
>
> > > > > > All I really need it to do is handle the stuff I want. I'd rather
> > not
> > > > have
> > > > > > to use toString() on it if I don't have to.
> > > > > > If I don't have to do that with a normal Class, then what's the
> > point
> > > > of it
> > > > > > being a string subclass?
>
> > > > > > —Thomas Aylott / subtleGradient
>
> > > > > > On Mar 10, 2009, at 11:12 PM, Sebastian Markbåge wrote:
>
> > > > > > About concatenation. I just added a test for that. new Uri('...')
> > +
> > > > > >> 'string' and 'string' + new Uri('...') both work as expected. So
> > > > > >> assuming it is two strings being concatenated it will work anyway.
> > You
> > > > > >> can also use it to test a regexp: (/^...$/).test(new Uri('...'))
>
> > > > > >> So I guess we're down to whether or not the String-manipulation
> > > > > >> methods such as substr, replace etc. are needed. And that boils
> > down
> > > > > >> to whether or not a URI is a String?
>
> > > > > --
> > > > > Guillermo Rauchhttp://devthought.com
>
> > > --
> > > Guillermo Rauchhttp://devthought.com
>
> --
> Guillermo Rauchhttp://devthought.com
