[bv-dev] Support for constraints on container values (e.g. Collection<@Email String>)

Thu Sep 29 06:13:41 EDT 2016

Hey Christian,

Thanks for your comments! Some answers inline.

--Gunnar

2016-09-25 11:22 GMT+02:00 Christian Kaltepoth <christian at kaltepoth.de>:

> Hey Emmanuel, Hey Gunnar,
>
> sorry for my late reply. Thank you very much for the enormous amount of
> work you already spent on this proposal. This topic seems to be quite
> complex and it looks like you spent many hours thinking about all this. It
> is a bit difficult to give good feedback without being so deep into this
> topic. But I'll try. ;-)
>
>    1. I was wondering whether the distinction between
>    SingleContainerValueExtractor and ManyContainerValuesExtractor is
>    really necessary. I'm not sure if the unnecessary instantiation of an
>    iterator in the single value case is really a problem in practice. I think
>    extractor implementations will provide some special implementation of the
>    Iterator/Iterable contract in any case. Not sure how others feel about
>    that.
>
> Good question. I reckon we'll know more after experimenting with this in
the RI.

>
>    1. Section 2.1 states that BV will support Iterable and Map by
>    default. What about Optional? We will support the JDK8 date/time API,
>    so why don't we plan to support Optional?
>
> Optional will be part of it by default. It should be stated somewhere, I
hope :)

>
>    1. I like the idea that users can provide custom extractors for other
>    container types. Not sure if this is something the average developer will
>    do very often, but defining an SPI here seems like a good idea.
>    2. I'm not completely sure if the "one extractor per container" or the
>    "one extractor per container + value" approach makes more sense. That's a
>    very difficult questions. I think I need some more time to think about that.
>
> Same here. Personally I'm not a huge fan of annotating the type parameter
of the extractor type with @ExtractedValue, it will be unfamiliar to many.
I tried to avoid it with the alternative proposal.
>
>
>    1. The concept of @ConstraintsApplyTo looks fine to me and makes a lot
>    of sense. Especially being able to use the annotation on the extractor AND
>    at the container declaration site.
>
> That's my first batch of feedback. Hope this helps.
>

Thanks, it does!

Christian
>
>
>
>
> 2016-09-19 16:29 GMT+02:00 Otávio Gonçalves de Santana <
> otaviopolianasantana at gmail.com>:
>
>> That's fine to me.
>>
>> On 19 Sep 2016 4:31 a.m., "Gunnar Morling" <gunnar at hibernate.org> wrote:
>>
>>> +1
>>>
>>> If everyone could take a look at this one, that'd be great! It's a bit
>>> more complex, so the more eyes we get on this one, the better.
>>>
>>> Thanks!
>>>
>>> 2016-09-19 13:28 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>>
>>>> This is probably going to be most visible feature of Bean Validation
>>>> 2.0. We particularly need your feedback and involvement on this one.
>>>>
>>>> Emmanuel
>>>>
>>>> On Tue 2016-09-06 18:12, Emmanuel Bernard wrote:
>>>> >Hi all,
>>>> >
>>>> >I and a few others have been working on a proposal to support things
>>>> >like Collection<@Email String> and Optional<@Email String>. This is
>>>> >more complicated that it seems at first glance.
>>>> >
>>>> >Instead of doing an ad-hoc support for the various collection types,
>>>> >Optional and the JavaFX Properties, we quickly decided to define the
>>>> >notion of container and the ability to declare constraints on contained
>>>> >elements to validate them.
>>>> >
>>>> >This lead to two main proposals that you can read at
>>>> >http://beanvalidation.org/proposals/BVAL-508/
>>>> >
>>>> >This is a relatively long read, you can start by ignoring "alternative"
>>>> >options for your first pass. We are very interested in feedback at this
>>>> >stage as we have been pushing these proposal very far already and they
>>>> >would need to become part of the spec as next step.
>>>> >
>>>> >Let me know of what you think, questions, remarks etc.
>>>> >
>>>> >In particular, I'm interested in what you think of the following.
>>>> >
>>>> >The capability to define custom containers.
>>>> >
>>>> >The extractor approach vs its alternative.
>>>> >
>>>> >The concepts of @ConstraintsAppliesTo(COMTAINED) used for JavaFX and
>>>> for
>>>> >subclasses of containers.
>>>> >
>>>> >@Valid, in particular the legacy and new forms and how to handle the
>>>> >transition.
>>>> >
>>>> >And finally, but a big one, what do you think of proposal 1 vs proposal
>>>> >2. The latter being more generic but with more open questions (and a
>>>> >less elaborated at this stage).
>>>> >
>>>> >Emmanuel
>>>> >_______________________________________________
>>>> >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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20160929/47ee62f6/attachment.html 