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

[Gunnar Morling]

2013/9/4 Gunnar Morling <gunnar at hibernate.org>

> (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.
>

Another use case may be Optional from JDK 8:

    @Size(min = 5)
    Optional<String> name;



>
>  --hardy
>>
>>
>