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

[Emmanuel Bernard]

Something like c makes sense.
It similar to the notion of converter in JPA.

But why not the following style of interfaces

    interface Convert<From,To> {
        To convert(From);
    }


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