8:58 a.m.
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
9:10 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:27 a.m.
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.
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):
@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
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
>
2:26 a.m.
2013/9/4 Emmanuel Bernard <emmanuel(a)hibernate.org>
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.
No, I'm not saying that. I also think we can separate that.
There is two steps involved:
* Resolve the correct validator for the validated element, using its
declared (static) type; E.g. in the following case we'd need to find the
validator for @Size/String:
@Size(min=3)
UIInput<String> name;
While in this case we'd have to throw an exception since there is no
validator for @Size/Object:
@Size(min=3)
UIInput<Object> name;
For this step I envisioned the method "Type getDeclaredType(Type
sourceType)" (better name to be found, unwrapDeclaredType()?), which would
return the "real" type to consider for validator resolution (here, String
or Object, respectively).
* If we have found the right validator, use it to validate the given value.
For this step I envisioned the getValidatedValue() method which obtains the
value from the given wrapped property before passing it to the validator.
--Gunnar
>
> @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
> >
2:49 a.m.
On Wed 2013-09-04 9:26, Gunnar Morling wrote:
2013/9/4 Emmanuel Bernard <emmanuel(a)hibernate.org>
> 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.
>
No, I'm not saying that. I also think we can separate that.
There is two steps involved:
* Resolve the correct validator for the validated element, using its
declared (static) type; E.g. in the following case we'd need to find the
validator for @Size/String:
@Size(min=3)
UIInput<String> name;
While in this case we'd have to throw an exception since there is no
validator for @Size/Object:
@Size(min=3)
UIInput<Object> name;
For this step I envisioned the method "Type getDeclaredType(Type
sourceType)" (better name to be found, unwrapDeclaredType()?), which would
return the "real" type to consider for validator resolution (here, String
or Object, respectively).
* If we have found the right validator, use it to validate the given value.
For this step I envisioned the getValidatedValue() method which obtains the
value from the given wrapped property before passing it to the validator.
What I am arguing then is that the getDeclaredType method is unnecessary if
the converter class captures the type already via the From parameterized
type.
3:50 a.m.
2013/9/4 Emmanuel Bernard <emmanuel(a)hibernate.org>
On Wed 2013-09-04 9:26, Gunnar Morling wrote:
> 2013/9/4 Emmanuel Bernard <emmanuel(a)hibernate.org>
>
> > 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.
> >
>
> No, I'm not saying that. I also think we can separate that.
>
> There is two steps involved:
>
> * Resolve the correct validator for the validated element, using its
> declared (static) type; E.g. in the following case we'd need to find the
> validator for @Size/String:
>
> @Size(min=3)
> UIInput<String> name;
>
> While in this case we'd have to throw an exception since there is no
> validator for @Size/Object:
>
> @Size(min=3)
> UIInput<Object> name;
>
> For this step I envisioned the method "Type getDeclaredType(Type
> sourceType)" (better name to be found, unwrapDeclaredType()?), which
would
> return the "real" type to consider for validator resolution (here, String
> or Object, respectively).
>
> * If we have found the right validator, use it to validate the given
value.
> For this step I envisioned the getValidatedValue() method which obtains
the
> value from the given wrapped property before passing it to the validator.
What I am arguing then is that the getDeclaredType method is unnecessary if
the converter class captures the type already via the From parameterized
type.
To make this work you'd need to declare a converter class for each possible
wrapped type:
StringUIInputConverter implements Converter<UIInput<String>> { ... }
IntegerUIInputConverter implements Converter<UIInput<Integer>> { ... }
...
This may be feasible in some cases, but not e.g. for Optional<T> which
basically can take every type. In this case you'd want to parameterize the
implementation like this:
class OptionalConverter implements Converter<Optional<?>> { ... }
Here you can't derive the wrapped type of a given element from the
converter class. But you can implement the required logic in a generic way
in getDeclaredType().
8:30 a.m.
On 3 Jan 2013, at 4:10 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
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);
}
Going back to Emmanuel mentioning @Convert. I am wondering whether using explicit
annotations would not be more appropriate than an SPI?
It would of course be more verbose, but maybe the "converter" annotation could
be applied on class level as well. The concern for me is really the
ambiguity
@Size(min=3, max=10)
UIInput<String> name;
introduces. What if @Null or @NotNull is used. Does it apply to the String or the UIInput
instance. It is not apparent anymore from the annotations what
is targeted. We already started introducing ambiguous cases in Bean Validation with method
validation (cross parameter constraints, exclusion from getters
from validated methods), I am not sure we should continue on this path.
Does the gain we achieve via the proposed SPI outweigh introducing even more border
cases?
--Hardy
9:03 a.m.
2013/9/4 Hardy Ferentschik <hardy(a)hibernate.org>
On 3 Jan 2013, at 4:10 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
> 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);
> }
Going back to Emmanuel mentioning @Convert. I am wondering whether using
explicit annotations would not be more appropriate than an SPI?
How exactly do you envision annotations to be used? Could you give an
example? I didn't understood Emmanuel's Convert type to be an annotation.
It would of course be more verbose, but maybe the
"converter" annotation
could be applied on class level as well. The concern for me is really the
ambiguity
@Size(min=3, max=10)
UIInput<String> name;
introduces. What if @Null or @NotNull is used. Does it apply to the String
or the UIInput instance. It is not apparent anymore from the annotations
what
is targeted.
That's a good question. One could define a precedence rule, e.g. apply on
the element itself and only if no suitable validator is found perform the
unwrapping. But admittedly that makes things a bit more complicated.
We already started introducing ambiguous cases in Bean Validation
with
method validation (cross parameter constraints, exclusion from getters
from validated methods), I am not sure we should continue on this path.
Does the gain we achieve via the proposed SPI outweigh introducing even
more border cases?
Are there any other approaches we could pursue? I definitely think offering
support for this kind of use case in one way or the other makes sense.
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4133
days inactive
4134
days old
8 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Gunnar Morling -
Hardy Ferentschik