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.
On Mon, Sep 19, 2016 at 8:31 AM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
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.
2016-09-19 13:28 GMT+02:00 Emmanuel Bernard <emmanuel(a)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.
> 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
> >This is a relatively long read, you can start by ignoring
> >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
> >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).
> >beanvalidation-dev mailing list
> beanvalidation-dev mailing list
beanvalidation-dev mailing list