This is an old comment from Matt that I did not fully understand until now. Here is my
reply.
On 29 août 2012, at 17:38, Matt Benson wrote:
>
> So the remaining question is do we also support the type-safe approach in parallel?
> I am inclined to think yes. We can do it on the same
`CrossParameterConstraintValidator`
> implementation:
>
>
> class CheckRetypedPasswordValidator implements
> CrossParameterConstraintValidator<CheckRetypedPasswordParameter> {
> void initialize(...) { ... }
>
> boolean isValid(Object[] parameterValues, ConstraintValidatorContext
context);
>
> boolean isValid(String username, String email, String password, String
retypedPassword,
> ConstraintValidatorContext context) {
> ...
> }
> }
>
> If the method validated has a matching signature, we use it, otherwise we use the
generic
> method.
>
I am inclined to think this can be done as an implementation detail of
a given CPCV. However, is it intended that multiple CPCV impls might
be enabled for a given CPC type, each presumably handling a different
method signature? It might actually be simpler in the long run to
promote the type-safe approach such that at most one CPCV with no
typesafe declarations could be enabled. Perhaps the spec should
provide an abstract TypesafeCrossParameterConstraintValidator that
makes the correct typesafe call.
Perhaps this class could provide a
method to check whether a given signature is supported, or this method
could be specified on the CPCV interface.
It looks like a type-safe approach would indeed be implemented that way
by a bean validation provider. ie implementing a
TypesafeCrossParameterConstraintValidator
that would select the expected methods or raise an exception.
But I don't think it would be beneficial for the user to actually expose this class
that could be used in the @Constraint annotation. The main problem is that we need the
user to tell us which type-safe methods need to be considered and that cannot be
expressed
fit well in annotations.
The alternative is to ask people to extend this class. I am always concern when we add a
class
as opposed to an interface in the spec, so I'm undecided on this approach.
The third alternative is to let people write how methods are selected but provide a helper
method
as you said.