With the near impenetrable size of the RFC compliant regular expression, and the people who are interested in different use cases (I actually have an application that only wants to validate the "address" from [email protected] everything after the @ sign will be the same.) I have a suggestion to propose for how to proceed with email validation.
A while back I wrote a phone validation routine(For US/Canadian numbers only). It validates a phone number, and uses a different regular expression based on enum, that says which parts of the phone number are required. After watching this thread over the weekend I made some improvements this morning. I was generating the regex in onValidate(). Now I'm generating the pattern as a part of the enum itself. I think that something like this could help to split the RFC compliant regex into manageable chunks, keep/and or increase the flexibility of email validation, without sacrificing RFC compliance, or the "speed" of the current RfcCompliantEmailAddressValidator#onValidate() routine. Tom Burton P.S. I have attached my PhoneValidator to give a better idea of what I mean. -----Original Message----- From: Guillaume Smet [mailto:[email protected]] Sent: Sunday, July 22, 2012 9:18 AM To: [email protected] Subject: Re: [vote] deprecate/remove EmailAddressValidator and move RfcCompliantEmailAddressValidator to core Hi Martijn, On Fri, Jul 20, 2012 at 2:49 PM, Martijn Dashorst <[email protected]> wrote: > [X] Keep it as currently implemented Or change their names if they are not clear enough. I think both implementations cover different use cases. In our apps, we usually favor a field for the email only and we build the "Full Name <email address>" from the according fields of the user account. My 2 cents. -- Guillaume
