7:40 a.m.
On 28 août 2012, at 21:51, Gunnar Morling wrote:
Hi,
Am 27.08.2012 15:37 schrieb "Emmanuel Bernard" <emmanuel(a)hibernate.org>:
>
>
> On 27 août 2012, at 10:51, Gunnar Morling wrote:
>>
>> For the “getter“ approach, getMethodValidator() would be defined on
ValidatorFactory, right? At least that was the original idea.
>
>
> Ah. I was thinking `getMethodValidator()` was hosted to `Validator`. The negative I
could see are:
>
> 1. `ValidatorContext` needs to be updated too
> 2. we would require to allow injection of `MethodValidator` in injectable
environments
> 3. we will need to duplicate `getConstraintsForClass` and `unwrap` in
`MethodValidator`
Hmmm, you're right about 1. and 2. No biggie though IMO.
I'm not sure about getConstraintsForClass(). Would it really be duplicated? I think
the following options would be possible:
* Validator#getConstraintsForClass() could return a descriptor describing all (bean and
method) constraints. No getConstraintsForClass() on MethodValidator.
* Validator#getConstraintsForClass() returns a descriptor of the bean constraints,
MethodValidator#getConstraintsForClass() returns a descriptor representing the method
level constraints.
Which one did you have in mind?
I prefer that the metadata API returns everything unless designing it becomes much
simpler. But then, when I ahve a MethodValidator, I want to know if a method is validated
using the metadata before calling it. so I want access to the info. Hence the
duplication.
Regarding unwrap(), I'm tempted to say we should have it anyways
on MethodValidator, or did you mean to unwrap via an implementation-specific Validator
interface? Also in the fluent approach, I think I'd slightly prefer
validator.getMethodValidator() (could also be validator.forMethods() //no argument
- return the same object as validator.getMethodValidator)
validator.unwrap(MyMethodValidator.class).providerSpecificMethod();
MyMethodValidator mv = myValidator.getMethodValidator().unwrap(MyMethodValidator.class);
over
MyMethodValidator mv = myValidator.unwrap(MyValidator.class).getMethodValidator();
The main reason being, that it is more obvious and one doesn't need a specific
Validator interface if one only wants to expose a specific MethodValidator interface. It
doesn't make a huge difference, though.
> Independently, they don't weight much (except point 3) but as a whole I wonder
if that's the right approach.
> What would be the negative points of putting it on `Validator`? It requires one
extra method call. Any other?
I'd just find it more natural to retrieve a (method) validator from a validator
factory instead from another validator. That way it's more regular IMO.
The thing is that I see it a bit differently than you. I see MethodValidator and the
method specific methods of Validator that we have isolated in a delegate. If some for
reason one wants to use both Validator and MethodValidator methods, it's easier and
more natural than having to go back to the VF and possibly reconfigure the validator
context twice.