Thanks all for your feedback. I've pushed an update to the API PR get
rid of the composition usage. Agreed it makes more sense that way.
One question regarding flags: Wouldn't it be simpler
for users to specify flags simply by using embedded flag expressions
directly in the regular expression?
In the proposed form it's consistent with the (already existing)
@Pattern constraint. I think it makes sense to handle all usages of
reg exps following the same style.
@Positive [...] can be even more generic and support float and
double
Ah, that's an interesting point. Indeed I'd also have found @Positive
useful when working on a demo. It's not huge, but then adding it
doesn't do harm either.
2017-03-25 9:02 GMT+01:00 Christian Kaltepoth <christian(a)kaltepoth.de>:
Hey Gunnar,
I agree with Marco and Guillaume: I don't think that there is a real benefit
if we use constraint composition. Why not let providers implement it
directly?
I'm fine with regexp. One question regarding flags: Wouldn't it be simpler
for users to specify flags simply by using embedded flag expressions
directly in the regular expression? At least this is how I would do it. ;-)
I'm fine with leaving them out for now. However, even if they are just
syntactic sugar, I think it would be valuable to have them in the long term,
because they are much easier to read.
Christian
2017-03-24 19:20 GMT+01:00 Marco Molteni <moltenma(a)gmail.com>:
>
> Hi Gunnar,
>
> 1. Constraint composition: I agree with Guillaume, I thinks is better let
> the providers do their own implementation.
> 2. Email regex: Good for me.
> 3. @Positive/@Negative: Ok.
>
> Thanks!
>
> Marco
>
>
>
> On Fri, Mar 24, 2017 at 3:54 PM, Guillaume Smet <guillaume.smet(a)gmail.com>
> wrote:
>>
>> Hi Gunnar,
>>
>> On Fri, Mar 24, 2017 at 2:43 PM, Gunnar Morling <gunnar(a)hibernate.org>
>> wrote:
>>>
>>> * 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).
>>
>>
>> I'm not convinced it's such a good idea to use constraint composition
for
>> @NotBlank and @NotEmpty. I would let the implementation to the providers,
>> especially since using constraint composition does not really buy us
>> anything in this case.
>>
>> --
>> Guillaume
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
--
Christian Kaltepoth
Blog:
http://blog.kaltepoth.de/
Twitter:
http://twitter.com/chkal
GitHub:
https://github.com/chkal
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev