Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
Added support for custom email patterns, provided via options.emailRegex.#1518
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
5497099 tob83cd1bComparejzaefferer commentedJul 10, 2015
I'm okay with making the email validation configurable, but I really want to avoid adding more options. Partly because there are too many already, partly because this would tie in the method even more into the core. To take a step back, why do you need this as an option? Could you override the email method as needed? Or use a custom email method when you need to the default on the same page? |
staabm commentedJul 10, 2015
I could of course use a separate email validation method. IMO email validation will only be different in the email format and per definition will not have other differences, so I decided to go this road. In case email method validation itself would be a separate plugin, how would I define options for it? Per se, I would love to reduce the jquery-validation core to less lines and have a built which only contains the rules I really need for a certain app. |
Pass it via options.emailRegex.Defaults to the W3C defined pattern for BC.Fix Test CS.
staabm commentedJul 10, 2015
As you already know, email pattern issues are the most reported errors in this tracker, therefore solving the issue using a config param is a must have for a lot of our users. (I am not saying it has to be a option passed to the validator). Is separating the core from the actual methods a step which requires a BC break or do you plan to solve it in a BC compatible way? |
staabm commentedJul 15, 2015
@jzaefferer what do you think, how to proceed? |
staabm commentedJul 16, 2015
I just tried the other way you proposed. In case we promote the example: // setup the validation// ...// place my override$.validator.methods.email=function(value,element){returnthis.optional(element)||/whatEverRegexILike/.test(value);} @jzaefferer wdyt? |
jzaefferer commentedJul 20, 2015
That looks good to me. |
staabm commentedJul 21, 2015
will open a doc PR then, thanks. |
Uses the current email regex per default to keep BC.