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