Re: [hibernate-dev] [Validator] Applying constraints to property objects
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