2013/9/4 Hardy Ferentschik <ha...@hibernate.org>
>
> On 3 Jan 2013, at 4:10 PM, Emmanuel Bernard <emman...@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@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
