2013/9/4 Gunnar Morling <gun...@hibernate.org>
> (using correct list now)
>
>
> 2013/9/3 Hardy Ferentschik <ha...@hibernate.org>
>
>>
>>
>>
>>
>> On 3 Sep 2013, at 15:58, Gunnar Morling <gun...@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
>>
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
