9:40 a.m.
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(a)hibernate.org>:
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.
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev