2:43 p.m.
Hi there,
picking up this thread on adding new constraints, I've sent PRs for
adding @NotBlank, @NotEmpty and @Email:
* https://github.com/beanvalidation/beanvalidation-api/pull/93
* https://github.com/beanvalidation/beanvalidation-spec/pull/149
We agreed on their usefulness already, so could you let me know by
Monday if you have any objections? I'd like us to cut an Alpha2
release of API and spec on Monday, so we can can get out the new stuff
done since Early Draft 1.
Some questions:
* Should @NotEmpty mandate the usage of constraint composition (as
it's done in the PRs)? It essentially prescribes an "implementation",
i.e. providers wouldn't even need a constraint validator for it. But
then this excludes any more efficient implementation a provider may
have (well, they could by special-handling this constraint).
* Any concerns about regexp() and flags() in @Email? I think they are
good, esp. since the spec doesn't mandate any specific form of valid
e-mail addresses, so these attributes can be used for fine-tuning if
needed. We made good experiences with that in the RI.
* I'm not convinced of @Positive / @Negative as they are are just
syntactic sugar for @DecimalMin(value="0", inclusive=false) /
@DecimalMax(value="0", inclusive=false). Hence I left them out. But we
can add them in a second round if someone feels strongly about them.
Thanks,
--Gunnar
2016-11-22 12:09 GMT+01:00 Gunnar Morling <gunnar(a)hibernate.org>:
2016-10-26 9:02 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
> On Wed 16-10-19 12:09, Gunnar Morling wrote:
> >* 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.
>
> About surrogate pairs, I am not at all familiar with it but could it be
> resolve with a provider specific global option to handle surrogate pairs
> or not.
> I suppose your reluctance to support it is because it will take extra
> CPU time for the common case correct?
It's not that so much, but more staying consistent with the semantics of
CharacterSequence/String#length().
The docs of @Size say "length of character sequence is evaluated", so
linking this to String#length() appears as the most natural and consistent
thing to do.
The docs of String#size() say "The length is equal to the number of Unicode
code units in the string". I.e. the length of "𠮷" is defined as 2, not 1.
I think the user is best off to implement their own validator or constraint
@CodePointCount. We could make it an option in the RI or provide such
constraint/validator in the RI, but then it's the first and only time I've
heard about this requirement so I'm not sure whether it pulls its weight.
> On another subject, one of the proposal was support for EL. Should we
> leave it to the providers? Or embrace it?
Good question. We could promote @ScriptAssert from the RI. What do others
think?
That remark in the survey was targeted towards cross-field validation, so
we'd need some more work on top of that (@ScriptAssert is a pure class-level
constraint atm.). I hope cross-field support to fall out of BVAL-214 by some
kind of detyped validator API, i.e. EL wouldn't even be needed for this use
case.
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev