Email and URL validators in ActiveModel
iain
I cannot remember a project where I didn't have to deal with email
fields.
They're 100% generic too.
I am willing to make a patch, but I'd thought I'd consult here first.
If so, how should we do it? Via a regex, or via the mail gem[1] ?
[1] http://my.rails-royce.org/2010/07/21/email-validation-in-ruby-on-rails-without-regexp/
Lailson Bandeira
--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Teng Siong Ong
that's why the introduction of the new validator.
Ryan Bigg
--
Ryan Bigg
Franck Verrot
Aaron Patterson
> I think making this a gem first would be a good start, and once its garnered major support then it will be merged into core. Not all applications have to validate email and URLs (although, a large majority do, I will concede)
I agree with this. A gem first would be a good start.
One problem is that pretty much every place I've worked has had different
rules for validating emails and urls. Some places are fine by using the
RFC, some places want their own specific business rules, etc.
I'd rather not have these types of validations in core as I've never
worked at two places that had the same validation rules.
--
Aaron Patterson
http://tenderlovemaking.com/
Nikos Dimitrakopoulos
Trejkaz
<aa...@tenderlovemaking.com> wrote:
>
> I'd rather not have these types of validations in core as I've never
> worked at two places that had the same validation rules.
Quite by coincidence, the same is true for validates_numericality_of.
Maybe we should pull that out to a gem too.
TX
Jason King
Trejkaz
> Weird, I've never worked on any project that had a numericality requirement
> not met by vno.
You must have mis-read. I said that validates_numericality_of also
exhibited this:
| I've never worked at two places that had the same validation rules.
To illustrate:
{ :greater_than => 2 }
Is a different validation rule to
{ :less_than => 10 }
But nonetheless, the *core* of the matter is that the format for "a
number" does not change - the subset of values you permit does.
In the same way,
{ :domain_in => /\.edu\./ }
Would be a different validation rule to
{ :domain_in => /\.jp$/ }
But nonetheless, the *core* of the matter is that the format for "an
email address" does not change - the subset of values you permit does.
I hope you can see the parallels.
TX
Rainer Frey
> In the same way,
>
> { :domain_in => /\.edu\./ }
>
> Would be a different validation rule to
>
> { :domain_in => /\.jp$/ }
Well, OK, the format of a standalone domain name is mostly considered the same.
> But nonetheless, the *core* of the matter is that the format for "an
> email address" does not change - the subset of values you permit does.
The format for an email is not, as was written earlier in this
thread.There are email
addresses that are not conformant to all related RFCs but perfectly
usable at least
in the context of a certain deployment. OTOH there are more or less esoteric RFC
conformant email address formats that are not much used or no longer
supported by
all current mailservers and not desirable in some applications. Examples:
* addresses with IPv4 address literals
* addresses with not fully qualified domains that are completed by the
mail submission agent
* addresses with internationalized domain names, maybe stored before
punycode conversion
...
Similar cases can be made for URLs.
So yes, the fomat of email addresses and URLs may be quite different
in different applications.
Rodrigo Rosenfeld Rosas
> ...
>
> Similar cases can be made for URLs.
>
> So yes, the fomat of email addresses and URLs may be quite different
> in different applications.
That doesn't mean that a gem should come first. DDH became famous among
other things for his "opinated software" policy. By the way, I've been
enjoyed a lot his recent book "Rework", although I've not finished it
yet. Highly recommended. As well as Jos� Valim's excellent book
"Crafting Rails Application".
Back to the subject, after the free merchandise, what I'm saying is that
this is a very common requirement and most developers don't (shouldn't?)
care that much about e-mail format. At least for 90% of the
applications. So, I don't see any reasons why not to include some
"validates_email_of" helper. It doesn't need to solve all cases. It can
have some options for specifying some regular expression or some lambda
for verifying the e-mail format in case someone is really worried about
it. It can even be customized in a global configuration per
project/engine/mountable application. There could be some pre-defined
options specified by symbol like :rfc_compliant,
:performant_verification, etc.
I just don't buy the idea to make this more difficult than it should be.
It is much simpler to evolute and understand better the validations
after they are provided on rails core distribution. Also, in the
beginning, there were lots of philosophies about Rails, like the 80/20
principle. No body talks about this anymore... In every web application
with a user sign up feature, there will be an e-mail validation. This is
probably over 90% of the web applications built with Rails. Even so,
this will require all of these developers to replicate the logic to
validate e-mail. Most of them will just extract this one from Rails
documentation:
validates_format_of :email, :with =>
/\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\Z/i
That is because, this is usually the first thing written in a new
application that requires a user to log in. In this stage, no one is
willing to invest any time on the e-mail validation rule. Usually this
will only happen if some customer complaint about not being able to
register himself because the system is rejecting his e-mail.
For my applications, I usually don't care very much about the format
because of the way I handle the registration part. The user doesn't
input any information in the register form, except his e-mail address.
Then, he is informed that there were sent instructions for continuing
the register process to his e-mail and he'll continue to register
following a link on the e-mail. That way I can know for sure that the
e-mail is valid.
So, I think that even if not perfect, Rails should not wait for any gem
before supporting e-mail and URL validations built-in, even though I
have a feeling that it won't happen based on what I've being observed
from the core-team point of view.
Best regards,
Rodrigo.
Ben Munat
joke.
Ben
Lailson Bandeira
+1 Both to including validates_as_email in core and that that regex is a joke.
Ben
On 2/11/11 10:38 AM, Rodrigo Rosenfeld Rosas wrote:
Em 11-02-2011 15:20, Rainer Frey escreveu:
...
Similar cases can be made for URLs.
So yes, the fomat of email addresses and URLs may be quite different
in different applications.
That doesn't mean that a gem should come first. DDH became famous among
other things for his "opinated software" policy. By the way, I've been
enjoyed a lot his recent book "Rework", although I've not finished it
yet. Highly recommended. As well as José Valim's excellent book
Brian Morearty
+1 for built-in URL and email validators.
Brian
On Feb 11, 4:01 pm, Lailson Bandeira <lail...@guava.com.br> wrote:
> That's it. I completely agree with Rodrigo.
> --
Xavier Noria
<rr.r...@gmail.com> wrote:
> validates_format_of :email, :with =>
> /\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\Z/i
That's an unfortunate example, will replace it with something else.
