[bv-dev] Hosting of method validation methods

[Gunnar Morling]

Hi,

Ok, originally I had seen MethodValidator as something on the same
level as j.v.Validator, but I see your point about MV being a delegate
and having everything available through j.v.Validator.

Between the fluent and the getter approach I'm undecided. Fluent
requires a typical user who performs parameter and return value
validation to specify the method/constructor only once compared to
getter, so that's a bit shorter for callers. OTOH it creates an
intermediate object for each validator retrieval as you say.

In the fluent approach, I'm wondering whether there could be the need
for asking a MethodValidator for its method/constructor. I don't think
so, but in that case we'd have to add another two methods.

Regarding unwrap(), in the fluent approach we need it on MV due to its
state. For the getter approach, one could unwrap a j.v.Validator
object into a specific MethodValidator type directly, but I wouldn't
like the fact that there would be two different ways for getting a
method validator, getMethodValidator() and unwrap(). So I think there
should be MethodValidator#unwrap() in either case.

--Gunnar


2012/8/29 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> 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.
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>