[bv-dev] Hosting of method validation methods

[Gunnar Morling]

Hi,

I had created a local branch with a separate MethodValidator interface. I
can clean this up and push to Github.

For the “getter“ approach, getMethodValidator() would be defined on
ValidatorFactory, right? At least that was the original idea.

--Gunnar
Am 27.08.2012 10:19 schrieb "Emmanuel Bernard" <emmanuel at hibernate.org>:

> Did you end up playing with forMethod vs getMethodValidator ? I must
> admit, I'd like to see them in action before choosing.
>
> What do others think. this is a decision between the following two
> approaches:
>
> ## Fluent approach
>
> public interface Validator {
>     MethodValidator<T> forMethod(Method method, T object);
>     MethodValidator<T> forConstructor(Constructor<T> constructor);
> }
>
> public interface MethodValidator<T> {
>     <T> Set<MethodConstraintViolation<T>> validateParameter(
>         Object parameterValue, int parameterIndex, Class<?>... groups);
>
>     <T> Set<MethodConstraintViolation<T>> validateAllParameters(
>         Object[] parameterValues, Class<?>... groups);
>
>     <T> Set<MethodConstraintViolation<T>> validateReturnValue(
>         Object returnValue, Class<?>... groups);
> }
>
> ## Getter approach
>
> public interface Validator {
>     MethodValidator getMethodValidator();
> }
>
> public interface MethodValidator<T> {
>     <T> Set<MethodConstraintViolation<T>> validateMethodParameter(
>         Method method, T object, Object parameterValue, int
> parameterIndex, Class<?>... groups);
>
>     <T> Set<MethodConstraintViolation<T>> validateAllMethodParameters(
>         Method method, T object, Object[] parameterValues, Class<?>...
> groups);
>
>     <T> Set<MethodConstraintViolation<T>> validateMethodReturnValue(
>         Method method, T object, Object returnValue, Class<?>... groups);
>
>     <T> Set<MethodConstraintViolation<T>> validateConstructorParameter(
>          Constructor<T> constructor, Object parameterValue, int
> parameterIndex, Class<?>... groups);
>
>     <T> Set<MethodConstraintViolation<T>> validateAllConstructorParameters(
>         Constructor<T> constructor, Object[] parameterValues, Class<?>...
> groups);
>
>     <T> Set<MethodConstraintViolation<T>> validateConstructorReturnValue(
>         Constructor<T> constructor, Object returnValue, Class<?>...
> groups);
> }
>
> ## Comparison
>
> The advantage of segregation is to avoid pollution of the
> main Validator interface especially if we add more methods in the future.
>
> The getter approach has the benefit of being simple.
>
> The fluent approach let's us factor the various methods between the
> methods and constructor calls and makes names less awkward. It also
> is consistent with some of the Bean Validation design using fluent APIs.
> The drawback of of fluent API is that it requires two method calls for a
> validation:
> • one to select the object and method
> • one to validate the parameters / return value
> It also creates a temporary object (returned by the first method).
>
> I have captured this discussion at
> http://beanvalidation.org/proposals/BVAL-241/#validating
> "DISCUSSION: Would a separate interface MethodValidator make sense?"
>
> Emmanuel
>
> On 1 août 2012, at 08:20, Gunnar Morling wrote:
>
> Hi,
>
> What do you other guys think?
>
> I'll go and create a branch to play around a bit with a separate
> MethodValidator interface. Maybe it helps to have something more specific
> which we then can compare and discuss.
>
> --Gunnar
> Am 26.07.2012 10:38 schrieb "Hardy Ferentschik" <hardy at hibernate.org>:
>
>>
>> On Jul 25, 2012, at 12:00 AM, Gunnar Morling wrote:
>>
>> > Hi,
>> >
>> > 2012/7/23 Hardy Ferentschik <hardy at hibernate.org>:
>> >> Hi all,
>> >>
>> >> Let me pick up yet another TODO from the current spec.
>> >>
>> >> Section "5.1.2. Method-level validation methods" [1] still contains a
>> TODO whether the methods for method validation should be hosted
>> >> on a different interface (other than javax.validation.Validator).
>> >>
>> >> At the moment all validation methods are hosted on
>> javax.validation.Validator. Personally I don't see a strong reason for
>> introducing
>> >> another indirection/interface. Does anyone have objections removing
>> the todo?
>> >
>> > I guess Emmanuel does :)
>> >
>> > Personally, I also used to be of the opinion that a separate interface
>> > doesn't really add much value. What made me pondering though was the
>> > recent discussion about adding new bean validation methods such as
>> > validateProperty(T object, Path property, Class<?>... groups);
>> >
>> > Following the interface segregation principle [1], it may indeed be a
>> > good idea to have two separate interfaces, one for standard bean
>> > validation and one for method validation. I think the main question
>> > is, who the consumers of the individual methods are. I think there may
>> > be a broader range of users of the bean validation methods
>> > (validate(), validateProperty() etc.) than of the method validation
>> > methods (validateParameters() etc.), which typically will only be
>> > invoked by authors of integration/glue code. So for users of the first
>> > group it would reduce complexity if the method validation stuff went
>> > into a separate interface.
>> >
>> > With respect to retrieving method validators, instead of something
>> > like Validator#forMethod(Method method) etc. I could also imagine
>> > ValidatorFactory#getMethodValidator(). Then one doesn't have to
>> > retrieve a new validator for each validated method/constructor.
>>
>> +1 for ValidatorFactory#getMethodValidator() in case we decide separate
>> interfaces
>>
>>
>> --Hardy
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120827/92286970/attachment-0001.html