[bv-dev] Cross parameter validation convergence
Emmanuel Bernard
emmanuel at hibernate.org
Fri Sep 7 05:29:20 EDT 2012
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.
More information about the beanvalidation-dev
mailing list