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

I definitely recommend EG members spend time on this proposal. That's exactly why having such a diverse EG is so valuable: getting feedback and input from different folks with different backgrounds. That's not to say to not circulate it further (great idea!), but we should do our homework first. I know it takes time, but that was part of the deal when you sold your soul and joined the EG ;) So thanks a lot for any feedback you may provide! 2016-09-27 6:15 GMT+02:00 Michael Nascimento <misterm(a)gmail.com&gt;: > > This is *super* complex. I wonder if we could get Alex Buckley and/or > Michael Ernst to take a look at it to make sure we're going on the > right direction. What do you think? > > PS: If they can't, I'll need a few hours of detailed reading to > provide any meaningful feedback. > > Regards, > Michael > > On Mon, Sep 19, 2016 at 8:31 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; > 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(a)hibernate.org&gt;: > >> > >> 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 > >> &gt;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 > > > > > > > > _______________________________________________ > > 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 _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev