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. ;-)
- I was wondering whether the distinction between SingleContainerValueEx
tractor 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.
- 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?
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.
- 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.
- 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.
- 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@gmail.com >:That's fine to me.
On 19 Sep 2016 4:31 a.m., "Gunnar Morling" <gunnar@hibernate.org> wrote:+1If 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@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@lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/ beanvalidation-dev