Make email validation pattern configurable

[philippd]

The pattern used to validate emails should be configurable. For example when used in combination with bean validation it makes sense to use the same pattern as the back-end.

Probably introduce a global valdrProvider.useBeanValidation() configuration function which enables the Java specific patterns for email and url... and probably others?

see also #23

[marcelstoer]

Probably introduce a global valdrProvider.useBeanValidation() configuration function which enables the Java specific patterns for email and url

If at all...don't call it "bean validation" because @Email and @URL are Hibernate proprietary and not pure BV (JSR 303).

Maybe it still makes sense for the (regex-)pattern based validators to have their own pattern configuration rather than this generic flag which would couple valdr to valdr Bean Validation. Otherwise, we'd have to introduce valdrProvider.use<dot-net-whatever>() and a valdrProvider.use<ruby-whatever>() and ... flags at some point.

[marcelstoer]

After some more thinking I suspect we'd actually have to provide a hibernateEmailValidator. If one would want to mimic the same behavior in the front-end as in the back-end the JavaScript validator would have to support the extra constraint attributes like regexp or host, port, etc. for a potential hibernateUrlValidator

[philippd]

Good idea. Then it would also not be necessary for valdr users to configure which one to use. The only thing we would have to change is the validator name the valdr-bean-validation servlet returns.

[marcelstoer]

The only thing we would have to change is the validator name the valdr-bean-validation servlet returns

You mean in the JSON we'd call it hibernateEmail instead of just email?

[philippd]

Yes, if we add it as a second independent validator we would have to use a different name for it and therefore in the JSON as well. Although this may not look so nice in the JSON, I still think it's better than having two validators with the same name and enabling the correct one via configuration on the client side. What do you think?

[marcelstoer]

What do you think

+1, that's what I proposed

Although this may not look so nice in the JSON

How it looks in the JSON is the least of my concerns. Whatever the name of the validator in the JSON is, it simply has to be one of the validators known to valdr (built-in or custom). What I'm more concern about is that we fall victim to feature creep even at that early stage of the project. Up to now the only thing that coupled valdr to valdr Bean Validation (or any other back-end provider) was the JSON. With this feature we'd allow one specific back-end provider (valdr Bean Validator) to have an influence on the front-end.

This opens the door for new desires with every now back-end provider that hopefully emerges. I'm willing to accept this because I still believe it'd be a valuable extension to our basic features. If it turns out to become a nightmare to maintain (a new Hibernate Validator release could potentially make a new valdr release necessary) we'd have to spin-off those provider-specific validators in their own projects.

-> I guess we should close this and open two new issues: implement hibernateEmailValidator, implement hibernateUrlValidator

[philippd]

i'll do that