On Thu, 5 Jul 2007, Tobias Schlitt wrote: > On 07/05/2007 10:27 AM Derick Rethans wrote: > > On Wed, 4 Jul 2007, Alexandru Stanoi wrote: > > >> Flexibility is the key here, so I propose this: > >> > >> validateEmailAddress - just regexp > >> verifyDomain - just checkdnsrr() or exec( 'nslookup' ) on Windows > >> convertToPunyCode - converts to Punycode > >> convertToUnicode - viceversa > >> > >> and it will be up to the developer to use these functions as he sees fit. > > > Yes, this idea sounds fine, but we need more descriptive method names. I > > would also make the rx checks as option to validateEmailAddress > > actually, as it's the same function and that shouldn't be done by two > > methods. I think that we should also see if we can do more than just > > "checkdnsrr()" (you mentioned some more advanced algorithm). > > I think the sense was, that options to a function are not good?
It's not bad just because it's an option... > Anyway, I dislike it here especially, since we force users to user our > regex, if they just want to perform our mx checks. It should be 2 > seperate methods. That makes sense though. > > The last two functions "convertToPunyCode" and "convertToUnicode" do > > actually not really belong in the Mail component at all, as they are > > generic methods. I think they actually belong more in Url. I would > > therefore suggest to create two methods on ezcUrl (and the algorithms it > > self in ezcUrlTools as static methods) that can convert a Url toASCII() > > (with the punycode algorithms) and toUnicode() with the reverse > > algorithm. (I am naming them toASCII() and toUnicode() here because > > that's what wikipedia suggests). > > That would mean a dependency Mail -> Url? No, why? AFAIK we basically agreed that we don't do any of those conversions ourselves, but that's up to the application. Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
