I was wondering: shouldn't email and url validators be in ActiveModel? 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/
+1. E-mails and URLs are basic and universal.
With the new validator, I don't think that this is necessary. I guess that's why the introduction of the new validator.
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’d be glad to help as I’ve already created (with other people) ActiveValidators.
FYI Iain, the email validation is based on the mail gem.
Franck
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.
I must say I agree. A good, stable and full featured gem is what’s needed. The only downside to this is that newcomers to the framework won’t know it and thus have to re-implement the wheel again and again, at least in their first steps. Could the gem be officially supported, possibly with a reference in the documentation?
Quite by coincidence, the same is true for validates_numericality_of. Maybe we should pull that out to a gem too.
TX
Weird, I’ve never worked on any project that had a numericality requirement not met by vno.
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
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.
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.
+1 Both to including validates_as_email in core and that that regex is a joke.
Ben
That’s it. I completely agree with Rodrigo.
Well said, Rodriguo. I'm convinced. Opinionated framework for the win.
+1 for built-in URL and email validators.
Brian
That's an unfortunate example, will replace it with something else.
+1 for URL and email validators.
Allen Madsen http://www.allenmadsen.com