As far as this goes, I agree that it makes sense to be flexible and
consistent with earlier specification versions; i.e. to permit annotation
of type parameters both on fields and their associated accessor methods.
With regard to the mechanism used for reaching the validated contained
values, my feeling is that some combination of the proposals at [1] is
correct (i.e. the explicitness of the original proposal plus the aspect of
your proposal to combine the extracted value with the associated
path/node). It would probably also be helpful to provide an
annotation-based shorthand for class developers to mark the extracted
elements of custom container types without having to write an extractor
implementation (which ties into my otherwise clueless response on an
earlier thread ;) ).
Matt
1.http://beanvalidation.org/proposals/BVAL-508/
On Dec 2, 2016 9:20 AM, "Gunnar Morling" <gunnar(a)hibernate.org> wrote:
Hi,
As you may have seen, Emmanuel started a survey on how people would like
to use type-level constraints in Bean Validation: http://
beanvalidation.org/news/2016/11/23/survey-constraints-and-
parameterized-type/
While we are waiting for some more replies to that one, I started with a
PoC implementation of the value extractor idea in the reference
implementation in order to get a better feeling for it, it's limitations,
open questions etc.:
https://github.com/hibernate/
hibernate-validator/pull/592
One thing we started to wonder is whether it should be allowed to put
type-level constraints to a field *and* the corresponding property getter
at the same time:
private List<@NotBlank String> strings;
public List<@Pattern(regexp="...") String> getStrings() { return
strings; }
My first inclination was to say that it should be supported (as you can
put regular constraints to a field and its getter). A challenge is how to
obtain the values for constraint validation. In the spirit of BV 1 we'd
have to iterate the values directly from the field for evaluating the
@NotBlank constraint and a second time through the getter for @Pattern
validation. That's a potential performance issue of course.
What do others think?
Thanks,
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev