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

[Gunnar Morling]

(using correct list now)


2013/9/3 Hardy Ferentschik <hardy at hibernate.org>

>
>
>
>
> On 3 Sep 2013, at 15:58, Gunnar Morling <gunnar at hibernate.org> 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);
> >    }
>
>

> How would such a processor work? In particular how does an implementation
>  decide whether the value needs to be unwrapped or just accessed directly?


I think an implementation would decide this by examining the declared type
of a property, parameter etc. E.g. the JavaFX Property processor would only
accept *Property typed elements and ignore all others. Probably there
should be another method "boolean accepts(Type declaredType)" which is
invoked by the engine for that purpose.


> Is there a need for configuring multiple processors?
>

Yes, I think so. So a user could work with wrapped types of different
kinds. Maybe we should even support nested wrapped elements such as
UIInput<StringProperty>. But this might be a second step.


> What other use case is there outside JavaFX?
>

The original use case is UIInput from Forge. Maybe other UI technologies
where one wants to apply validation to some kind of form object with UI
controls instead of a backing bean model.

--hardy
>
>