[bv-dev] BV 2.0 - Add constraints?

[Gunnar Morling]

2016-10-22 9:31 GMT+02:00 Christian Kaltepoth <christian at kaltepoth.de>:

> 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.
>

I've filed https://hibernate.atlassian.net/browse/BVAL-548 for the
constraints above and @Email. Should have a proposal done for it quickly
unless someone else feels like going for it.

* 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?
>

I've got the same feeling, too.

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
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161122/095d67d6/attachment.html