[bv-dev] BV 2.0 - Add constraints?

[Christian Kaltepoth]

Hey Gunnar,

thanks a lot for summarizing the results of the survey. See some comments
inline:


The survey has closed and we got some very interesting results from it (240
> answers):
>
> * 97.9% wish for @NotEmpty
> * 87.9% wish for @NotBlank
> * 72.9% wish for @Positive/@Negative
>

I expected these to be voted very often. These constraints are really
useful and therefore I think it would be very valuable to add them to the
spec.


* @Email is mentioned several times. As said in my blog post I'm very
> skeptical about supporting it, as a) requirements around e-mail validation
> are very different for different scenarios) and b) specs/RFCs around e-mail
> are not necessarily consistent. Hence I'm concerned about entering a mine
> field of everlasting bug reports around it.
>
> But Emmanuel made an interesting proposal that may work: Add the @Email
> constraint itself but leave the specific interpretation to BV providers.
> That'd make code using it portable in terms of compilation, but runtime
> behavior may differ of course. Feedback on this idea is welcome.
>

Validating email addresses is a very common requirement. And therefor I
agree with people that it would be good to have it in the BV spec. However,
I also agree with Gunnar that validating email addresses isn't easy and
there are many weird corner cases. I actually like Emmanuel's idea. We
define the constraint in the spec and implementing the details correctly is
up to the BV implementation. IMO this is fine even if BV implementations
behave differently for certain corner cases which are usually very rare.


* Another interesting one is support for Unicode surrogate pairs (it's
> mentioned several times, though I'm not sure whether that was not one and
> the same person, given I've *never* heard about requests for it before).
> The issue is that there are characters with a code unit greater than what
> can be stored in two bytes. These are represented by "surrogate pairs",
> causing for instance "𠮷".length() to return 2 and not 1 as one may expect.
> Hence values given in @Size need to take that into account. I feel people
> are best off with a custom validator addressing this case, but I'd be
> curious to hear what others think. We may explore support in the RI.
>

That really looks too specific in my opinion. But I may be wrong about
that. Other thoughts?


One more theme is cross-field / simpler class-level validation support. I
> hope we may address this in the course of BVAL-214.
>

+1


Christian


-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161022/326f70f5/attachment.html