Something like c makes sense.
It similar to the notion of converter in JPA.
But why not the following style of interfaces
interface Convert<From,To> {
To convert(From);
}
On Tue 2013-09-03 15:58, Gunnar Morling 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);
> }
>
> 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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
