On the subject, Gunnar and I were discussing three valid options to
define a constraint as cross-parameter constraint:
## @CrossParametersConstraint
(first off I hate the name, can't we find a better one?)
@Constraint(validatedBy=ObjectScriptAssert.class)
@CrossParametersConstraint(validatedBy=ObjectScriptAssert.class)
public @interface ScriptAssert { ... }
## @Constraint for both
@Constraint(validatedBy=ObjectScriptAssert.class
validatedByForCrossParameters=ObjectScriptAssert.class)
public @interface ScriptAssert { ... }
## @Validates on ConstraintValidator
@Constraint(validatedBy=ObjectScriptAssert.class)
public @interface ScriptAssert { ... }
@Validates({CROSS_PARAMETERS, ANNOTATED_ELEMENTS})
public class ObjectScriptAssert implements
ConstraintValidator<ScriptAssert,Object[]> { ... }
## Thoughts
I think I like @CrossParametersConstraints more than @Constraint for
both as it makes things explicit and keep the simple use case as is.
But I am intrigued by the @Validates option. In many ways, it's similar
to how we resolve the right constraint validator based on the type. The
only difference is that the @Validates annotation refines how Object[]
should be interpreted. It "fits better" in my opinion.
My concern around the latest option is that it forces us to be a
subclass of ConstraintViolation for the foreseeable future including
when we reopen the type-safe options we explored in
http://beanvalidation.org/proposals/BVAL-232/
Thoughts and comments?
Emmanuel
On Tue 2013-01-15 15:14, Gunnar Morling wrote:
2013/1/15 Emmanuel Bernard <emmanuel(a)hibernate.org>
> I can live with that but we must make it crystal clear that in case of
> ambiguity, we raise an exception. Otherwise, someone changing the method
> sig might have some nasty surprises.
>
And which of the options
@CrossParameterConstraint(validatedBy=MyCrossParameterValidator.class)
@Constraint(validatedBy=MyGenericValidator.class)
public @interface MyConstraint { ... }
vs.
@Constraint(
validatedBy=MyGenericValidator.class,
crossParameterValidatorType=MyCrossParameterValidator.class
)
public @interface MyConstraint { ... }
would you prefer?
Personally I'd lean towards the latter, since there would be exactly one
meta-annotation denoting an annotation as constraint annotation type, with
all attributes for the required configuration.
If following the 2nd approach, we should IMO add a default clause to
validatedBy() (set to the empty array), allowing for
the convenient definition of cross-parameter only constraints. According to
[1] this change would be binary-compatible.
But this is no strong preference, I could also live with the two separate
annotations.
--Gunnar
[1]
http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interface...
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev