[bv-dev] BV 2.0 - Add constraints?

[Gunnar Morling]

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 at 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 at 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 at gmail.com>
>> wrote:
>>>
>>> Hi Gunnar,
>>>
>>> On Fri, Mar 24, 2017 at 2:43 PM, Gunnar Morling <gunnar at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev