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
