You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Need a way to overwrite the email validate logic. #7798
I think you should stop trying to replace the email validation, because this is what email validation is on the web. Does it suck? Well sure, email sucks, but it's what we've got. This is how it works in your browser as well, or at least will be shortly once the last PR for email validation lands.
If you want to enforce that emails are from a specific TLD or something, or even just ensure that they HAVE a TLD, just add a pattern, really. This same line of thinking has been covered at the WHATWG
I agree that something should be done about this, since it will pop up over and over again. Would it conflict with HTML5 constraint validation if the regex angular uses was configurable? Once email & input are merged, it'll also be possible to overwrite the validator. We could mention that or the pattern way in the docs.
you can't actually include a port number in email hosts, but if we're accepting that then that's a bug to fix in angular. You can extend validation with ng-pattern, however.
If there's not gonna a configurable way to change the regex we should update the email docs with info about the regex used and forms guide / ngmodel docs how to customize / overwrite validators. I can do that next week.
----- Ursprüngliche Nachricht -----
Von: "Igor Minar" [email protected]
Gesendet: 02.10.2014 00:37
An: "angular/angular.js" [email protected]
Cc: "Narretz" [email protected]
Betreff: Re: [angular.js] Need a way to overwrite the email validate logic.(#7798)
you can override the email regexp by reimplementing the email validator. it should be just a few lines of code:
myModule.directive('myCustomeEmailValidator', function() {
return {
require: 'ngModel',
link: function($scope, $element, $attrs, ngModelController) {
var MY_EMAIL_REGEXP = /\[email protected]/;
ngModelController.$validators.email = function(value) {
return ctrl.$isEmpty(value) || MY_EMAIL_REGEXP.test(value);
};
}
}
});
can we close this issue?
—
Reply to this email directly or view it on GitHub.=
And if the custom directive or pattern has different rule, then both will be applied to validate the email.
It's actually not overwriting the exist email pattern, it's adding a new validation rule.
This is still an imperfect solution; if I want custom email validation that is stricter-than-spec (and, like everybody including Google, I do), then I want to apply those standards consistently across every email input in my application, without the risk that somebody will forget to add whatever customEmailValidation directive I create to one of them. This is why people are calling for the ability to customise the type=email validation, which still isn't possible.
The example in the documentation works pretty well but you should consider to add an easiest way to override the regex, it may be useful to all those who want to take advantage of the custom keyboard provided thanks to the type attribute but at the same time define a custom validation pattern.
A practical example could be an ipv4/dns field, where the most appropriate input type is url.
@fttx, you can already use ngPattern (which is super easy to setup) on a per-case basis.
And even if you want to overwrite the validator globally (i.e. for all input[type="email"] fields), a really short directive is all it takes:
.directive('input',function(){return{restrict: 'E',require: '?ngModel',link: function(scope,elem,attrs,ctrl){if(ctrl&&ctrl.$validators.email){ctrl.$validators.email=function(value){returnctrl.$isEmpty(value)||/* YOUR REGEXP */.test(value);};}}};});
Even if we provided a way to overwrite it globally per app, it wouldn't be much simpler than that (there would be some provider that would have to inject during the config phase and call some function that sets the e-mail RegExp etc).
Considering it is not too common a usecase and there are already adequate ways available for handling it, I'd say we shouldn't add more bloat to core.
Note you can always provide this fuctionality and a separate module and just add it as a dependency to your app.
Activity
lord2800 commentedon Jun 13, 2014
ng-pattern="/my-regex/"?jswxwxf commentedon Jun 13, 2014
Thanks for answering:)
I know ng-pattern, but it's adding regex check on the email, not replacing the build-in one.
caitp commentedon Jun 13, 2014
I think you should stop trying to replace the email validation, because this is what email validation is on the web. Does it suck? Well sure, email sucks, but it's what we've got. This is how it works in your browser as well, or at least will be shortly once the last PR for email validation lands.
If you want to enforce that emails are from a specific TLD or something, or even just ensure that they HAVE a TLD, just add a pattern, really. This same line of thinking has been covered at the WHATWG
jswxwxf commentedon Jun 19, 2014
Yes, I want to use angularjs's buildin email validator also, but the requirement is always from customers...
Narretz commentedon Jun 23, 2014
I agree that something should be done about this, since it will pop up over and over again. Would it conflict with HTML5 constraint validation if the regex angular uses was configurable? Once email & input are merged, it'll also be possible to overwrite the validator. We could mention that or the pattern way in the docs.
caitp commentedon Jun 23, 2014
the email validator should really match what browsers do --- however we could make it possible to register "extra" validation logic to it.
rolfyone commentedon Jun 28, 2014
are there examples of 'valid' emails that currently fail validation that lead to this being needed?
is this just the something@some kind of scenario mentioned in #7979 or are there others too that are of specific concern?
jimmywarting commentedon Jul 18, 2014
one invalid email that passes in angular (but not in the browser) is something@some:aaaa where the port can only be a number
caitp commentedon Jul 18, 2014
you can't actually include a port number in email hosts, but if we're accepting that then that's a bug to fix in angular. You can extend validation with ng-pattern, however.
jimmywarting commentedon Jul 18, 2014
you are right @caitp, I mixed it up with url
10 remaining items
Narretz commentedon Oct 2, 2014
If there's not gonna a configurable way to change the regex we should update the email docs with info about the regex used and forms guide / ngmodel docs how to customize / overwrite validators. I can do that next week.
----- Ursprüngliche Nachricht -----
Von: "Igor Minar" [email protected]
Gesendet: 02.10.2014 00:37
An: "angular/angular.js" [email protected]
Cc: "Narretz" [email protected]
Betreff: Re: [angular.js] Need a way to overwrite the email validate logic.(#7798)
you can override the email regexp by reimplementing the email validator. it should be just a few lines of code:
myModule.directive('myCustomeEmailValidator', function() {
return {
require: 'ngModel',
link: function($scope, $element, $attrs, ngModelController) {
var MY_EMAIL_REGEXP = /\[email protected]/;
ngModelController.$validators.email = function(value) {
return ctrl.$isEmpty(value) || MY_EMAIL_REGEXP.test(value);
};
}
}
});
can we close this issue?
—
Reply to this email directly or view it on GitHub.=
IgorMinar commentedon Oct 2, 2014
@Narretz please do!
docs(guide/forms, input): add information how to modify built-in vali…
docs(guide/forms, input): add information how to modify built-in vali…
docs(guide/forms, input): add information how to modify built-in vali…
kemins commentedon Apr 8, 2015
so there is still no way to set TLD as required without writing custom directive or pattern.
jswxwxf commentedon Apr 8, 2015
And if the custom directive or pattern has different rule, then both will be applied to validate the email.
It's actually not overwriting the exist email pattern, it's adding a new validation rule.
Narretz commentedon Apr 8, 2015
There's an example that shows how to overwrite the email validator: https://docs.angularjs.org/guide/forms#modifying-built-in-validators
ExplodingCabbage commentedon Apr 14, 2015
This is still an imperfect solution; if I want custom email validation that is stricter-than-spec (and, like everybody including Google, I do), then I want to apply those standards consistently across every email input in my application, without the risk that somebody will forget to add whatever
customEmailValidationdirective I create to one of them. This is why people are calling for the ability to customise thetype=emailvalidation, which still isn't possible.gkalpak commentedon Apr 14, 2015
@ExplodingCabbage: You can still apply the custom validation to every
input[type="email"]with the appropriate directive. E.g.:ExplodingCabbage commentedon Apr 14, 2015
@gkalpak oh, wow, I'd always assumed that all directives had to have unique names. Thanks for very usefully pointing out my error!
fttx commentedon Feb 14, 2016
The example in the documentation works pretty well but you should consider to add an easiest way to override the regex, it may be useful to all those who want to take advantage of the custom keyboard provided thanks to the type attribute but at the same time define a custom validation pattern.
A practical example could be an ipv4/dns field, where the most appropriate input type is url.
gkalpak commentedon Feb 16, 2016
@fttx, you can already use
ngPattern(which is super easy to setup) on a per-case basis.And even if you want to overwrite the validator globally (i.e. for all
input[type="email"]fields), a really short directive is all it takes:Even if we provided a way to overwrite it globally per app, it wouldn't be much simpler than that (there would be some provider that would have to inject during the config phase and call some function that sets the e-mail RegExp etc).
Considering it is not too common a usecase and there are already adequate ways available for handling it, I'd say we shouldn't add more bloat to core.
Note you can always provide this fuctionality and a separate module and just add it as a dependency to your app.