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

Gunnar Morling gunnar at hibernate.org
Tue Nov 22 06:36:55 EST 2016


Just replying to this one:

> == Constraint on non parameterized containers
> I am liking option 3 less and less and as far as I can remember, it does
not rely on an explicitly
> identified use case. Who is wanting to support that usage, vs restrict
the container feature to
> parameterized containers?

I'm not sure where this requirement is coming from. Wouldn't it simply be
addressed by providing a validator for @Min + IntegerContainer? I.e. do we
need any explicit support for this at all compared to what's possible today?

Also the JavaFX case (your 2nd example around StringProperty) could be
satisfied by just adding explicit validators for StringProperty,
IntegerProperty etc. Agreed it's not as elegant/generic and wouldn't work
for custom types. May still be a way forward, though.

2016-11-21 14:28 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:

>
> On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers at me.com> wrote:
>
> In addition I think that simply adding a constraints annotation to the
> generic type is wrong. All examples that we have mentioned are just perfect
> examples in that the generic type defines the content. Let’s say we have a
> class like this:
>
> public abstract class ConvertableInteger<V> {
>
> private int value;
>
> public void setValue(int value) { this.value = value; }
>
> public int getValue() { return value; }
>
> public abstract V getConvertedValue();
> }
>
> If you want to validate an instance of this class you normally want to
> validate the integer and not the converted value:
>
> private ConvertableInteger<@Min(2_000_000) Date> myValue;
>
> Such an expression looks like if you want to validate a Date object. In
> this case the better solution would be something like this:
>
> @Min(2_000_000)
> private ConvertableInteger<Date> myValue;
>
>
> And now we end in 2 different ways how we annotation value wrappers:
>
> private CachableValue<@NotEmpty String> myCachedValue;
>
> @Min(2_000_000)
> private ConvertableInteger<Date> myIntegerValue;
>
>
> First off, your specific example does not work as is as the class is
> abstract. You would need an explicit subclass (e.g. DateConvertableInteger
> extends ConvertableInteger<Date>). And in that situation, The more natural
> BV approach would be to do this:
>
> public class DateConvertableInteger extend ConvertableInteger<Date> {
>
>     @Min(@2_000_000)
>     public int getValue() { return value; }
>
>     @NotEmpty
>     public Date getConvertedValue();
> }
>
> class SomeClass {
>     @Valid
>     private StringConvertableInteger myValue;
> }
>
> == overriding constraint declarations
>
> Now if you want a way to override the constraints of an embedded (@Valid)
> object (graph), then I think that is a different subject that we can try
> and address. JPA for example has the notion of @AttributeOverride. It is
> more complicated in the case of Bean Validation as we would need to
> override actual annotations. Not sure how to express that for now. Do we
> think that it is a valid and important requirement?
>
> To clarify, here is what is required
>
> public class Embeddable {
>     @NotEmpty String foo;
> }
>
> public class Entity {
>     @Valid @Override(path=“foo”, constraints=@Min(3)) // note that this is
> not valid Java syntax
>     Embeddable embeddable;
> }
>
> == Constraint on non parameterized containers
>
> That raises another question, the proposal allows to to three things:
>
> - apply constraints on a type use generic declaration(*):
> Collection<@NotEmpty String> foo;
> - apply constraints on specialized generic parameters (*): @Pattern(…)
> StringProperty prop; //where StringProperty extends Property<String>
> - apply constraints on container with no generic: @Min(3) IntegerContainer
> prop; // where class IntegerContainer{ Integer value; } i.e. no generic
>
> (*) I don’t know the actual proper names so sorry if I butchered notions
>
> I am liking option 3 less and less and as far as I can remember, it does
> not rely on an explicitly identified use case. Who is wanting to support
> that usage, vs restrict the container feature to parameterized containers?
>
> I’m not sure I was all that clear, so please ask any question if you have
> any doubt.
>
> Emmanuel
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161122/38d00e42/attachment-0001.html 


More information about the beanvalidation-dev mailing list