[bv-dev] Hosting of method validation methods

[Emmanuel Bernard]

On 28 août 2012, at 21:51, Gunnar Morling wrote:

> Hi,
> 
> Am 27.08.2012 15:37 schrieb "Emmanuel Bernard" <emmanuel at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120829/2b21a28a/attachment-0001.html