[hibernate-dev] [Validator] Applying constraints to property objects

[Gunnar Morling]

2013/9/3 Emmanuel Bernard <emmanuel at hibernate.org>

> Something like c makes sense.
>

Ok.


> It similar to the notion of converter in JPA.
>
> But why not the following style of interfaces
>
>     interface Convert<From,To> {
>         To convert(From);
>     }
>

Yes, thinking more about it, it probably makes sense to support multiple
converters, e.g. in case someone works with UIInput and *Property in the
same application. Then the "From" parameter makes sense to avoid casts
within the converter implementation. Need to experiment with it a bit.

Regarding the name, I find "Converter" a bit too generic, in particular
since it needs not only to convert the actual property value but also the
static type so you can reject this (because @Size can't be applied to
Object):

    @Size(min=3, max=10)
    UIInput<Object> name;


On Tue 2013-09-03 15:58, Gunnar Morling wrote:
> > Hi,
> >
> > Yesterday George Gastaldi from the Forge team approached me regarding the
> > application of constraints to "wrapped" properties. Their situation is
> the
> > following:
> >
> >     ...
> >     @Size(min=3, max=10)
> >     UIInput<String> name;
> >     ...
> >
> > Here, UInput is some kind of UI component, wrapping the actual property
> > value. As is, validation of this property will fail since there is no
> > validator for applying @Size to UIInput (only for String).
> >
> > A similar use case exists in JavaFX where one might want to apply
> > constraints to the FX *Property types:
> >
> >     ...
> >     @Min(5)
> >     IntegerProperty count = new SimpleIntegerProperty(4);
> >     ...
> >
> > Again, validation will fail out of the box, as no validator for applying
> > @Min to IntegerProperty exists (but for int/Integer).
> >
> > How could this be solved? The following alternatives came to my mind:
> >
> > a) Create and register validators for these wrapper types, e.g.
> > ConstraintValidator<Size, UIInput> etc.
> >
> > Pro: Works with the existing APIs without modification
> > Con: Lots of code to write, either duplicating code or delegating to
> > (internal) implementation types; doesn't automatically benefit from new
> > built-in validators
> >
> > b) Apply constraints to getters instead of fields:
> >
> >     IntegerProperty count = new SimpleIntegerProperty(4);
> >
> >     @Min(5)
> >     int getCount() {
> >         return count.getValue();
> >     }
> >
> > Pro: Works with the existing APIs without modification; benefits from any
> > newly added built-in validators
> > Con: There may be cases where there is no such getter, e.g. for parameter
> > validation
> >
> > c) Provide an SPI which allows to plug in a custom "value processor"
> > implementation, retrieving the wrapped object and its "declared" type:
> >
> >     public interface ValidationValueProcessor {
> >         Object getValidatedValue(Object source);
> >         Type getDeclaredType(Type sourceType);
> >     }
> >
> > For the original example, the methods would return the name value and
> > String.class, respectively.
> >
> > Note that validator resolution is done using the static type of a
> property,
> > so I think the original example above should be supported, but the
> > following should not as no validator for @Size/Object exists:
> >
> >     @Size(min=3, max=10)
> >     UIInput<Object> name;
> >
> > Pro: Benefits from any newly added built-in validators, allows directly
> > annotating "wrapped" properties, requires no implementation by the user
> > besides the ValidationValueProcessor
> > Con: new HV-specific (at least for the time being) SPI
> >
> > I think a) creates prohibitively high efforts for the user/integrator, b)
> > lacks support for method constraints, so I think c) should be
> implemented,
> > possibly making this a spec SPI later on.
> >
> > Does anyone have other preferences or alternatives? If you also think c)
> > makes most sense, do you have a good/better idea for the interface and
> > method names?
> >
> > Thanks,
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>