2:05 a.m.
On Wed 2013-09-04 8:27, Gunnar Morling wrote:
2013/9/3 Emmanuel Bernard <emmanuel(a)hibernate.org>
> Something like c makes sense.
>
Ok.
> It similar to the notion of converter in JPA.
>
> But why not the following style of interfaces
>
> interface Convert<From,To> {
> To convert(From);
> }
>
Yes, thinking more about it, it probably makes sense to support multiple
converters, e.g. in case someone works with UIInput and *Property in the
same application. Then the "From" parameter makes sense to avoid casts
within the converter implementation. Need to experiment with it a bit.
More than just the cast in the impl, its a way to statically know that
you have a converter that takes From and only From, so you can restrict
the list of converters to consider to 0 or 1 all the time (assuming we
don't support multiple converters of the same From.
Regarding the name, I find "Converter" a bit too generic, in particular
since it needs not only to convert the actual property value but also the
static type so you can reject this (because @Size can't be applied to
Object):
Not sure I follow, before the core HV work, it converts a property or
class from From to To and from there you are good to go.
Are you saying that if From = UIInput<String> we would not be able to
separate it from UIInput<Object> statically? I *think* we can, just like
we do for collections in JPA.
@Size(min=3, max=10)
UIInput<Object> name;
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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>