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

[Christian Kaltepoth]

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.
   2. 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?
   3. 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.
   4. 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.
   5. 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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20160925/ceb7029b/attachment-0001.html