(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.
--hardy
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
