<p>Hi,</p>
<p>I had created a local branch with a separate MethodValidator interface. I can clean this up and push to Github.</p>
<p>For the “getter“ approach, getMethodValidator() would be defined on ValidatorFactory, right? At least that was the original idea.</p>
<p>--Gunnar<br></p>
<div class="gmail_quote">Am 27.08.2012 10:19 schrieb "Emmanuel Bernard" <<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Did you end up playing with forMethod vs getMethodValidator ? I must admit, I'd like to see them in action before choosing.<div><br></div><div>What do others think. this is a decision between the following two approaches:</div>
<div><br></div><div>## Fluent approach</div><div><br></div><div><div>public interface Validator {</div><div> MethodValidator<T> forMethod(Method method, T object);</div><div> MethodValidator<T> forConstructor(Constructor<T> constructor);</div>
<div>}</div><div><br></div><div>public interface MethodValidator<T> {</div><div> <T> Set<MethodConstraintViolation<T>> validateParameter(</div><div> Object parameterValue, int parameterIndex, Class<?>... groups);</div>
<div><br></div><div> <T> Set<MethodConstraintViolation<T>> validateAllParameters(</div><div> Object[] parameterValues, Class<?>... groups);</div><div><br></div><div> <T> Set<MethodConstraintViolation<T>> validateReturnValue(</div>
<div> Object returnValue, Class<?>... groups);</div><div>}</div><div><br></div><div>## Getter approach</div><div><br></div><div><div>public interface Validator {</div><div> MethodValidator getMethodValidator();</div>
<div>}</div><div><br></div><div>public interface MethodValidator<T> {</div><div> <T> Set<MethodConstraintViolation<T>> validateMethodParameter(</div><div> Method method, T object, Object parameterValue, int parameterIndex, Class<?>... groups);</div>
<div><br></div><div> <T> Set<MethodConstraintViolation<T>> validateAllMethodParameters(</div><div> Method method, T object, Object[] parameterValues, Class<?>... groups);</div><div><br></div>
<div> <T> Set<MethodConstraintViolation<T>> validateMethodReturnValue(</div><div> Method method, T object, Object returnValue, Class<?>... groups);</div><div><br></div><div><div> <T> Set<MethodConstraintViolation<T>> validateConstructorParameter(</div>
<div> Constructor<T> constructor, Object parameterValue, int parameterIndex, Class<?>... groups);</div><div><br></div><div> <T> Set<MethodConstraintViolation<T>> validateAllConstructorParameters(</div>
<div> Constructor<T> constructor, Object[] parameterValues, Class<?>... groups);</div><div><br></div><div> <T> Set<MethodConstraintViolation<T>> validateConstructorReturnValue(</div>
<div> Constructor<T> constructor, Object returnValue, Class<?>... groups);</div></div><div>}</div></div><div><br></div><div>## Comparison</div><div><br></div><div>The advantage of segregation is to avoid pollution of the main Validator interface especially if we add more methods in the future.<br>
<br>The getter approach has the benefit of being simple.<br><br>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.<br>
The drawback of of fluent API is that it requires two method calls for a validation:<br><div><span style="white-space:pre-wrap"> </span>• one to select the object and method<br></div><div><span style="white-space:pre-wrap"> </span>• one to validate the parameters / return value<br>
</div>It also creates a temporary object (returned by the first method).</div><div><br></div><div>I have captured this discussion at <a href="http://beanvalidation.org/proposals/BVAL-241/#validating" target="_blank">http://beanvalidation.org/proposals/BVAL-241/#validating</a></div>
<div>"DISCUSSION: Would a separate interface MethodValidator make sense?"</div><div><br></div><div>Emmanuel</div><div><br><div><div>On 1 août 2012, at 08:20, Gunnar Morling wrote:</div><br><blockquote type="cite">
<p>Hi,</p><p>What do you other guys think?</p><p>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.</p>
<p>--Gunnar</p>
<div class="gmail_quote">Am 26.07.2012 10:38 schrieb "Hardy Ferentschik" <<a href="mailto:hardy@hibernate.org" target="_blank">hardy@hibernate.org</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Jul 25, 2012, at 12:00 AM, Gunnar Morling wrote:<br>
<br>
> Hi,<br>
><br>
> 2012/7/23 Hardy Ferentschik <<a href="mailto:hardy@hibernate.org" target="_blank">hardy@hibernate.org</a>>:<br>
>> Hi all,<br>
>><br>
>> Let me pick up yet another TODO from the current spec.<br>
>><br>
>> Section "5.1.2. Method-level validation methods" [1] still contains a TODO whether the methods for method validation should be hosted<br>
>> on a different interface (other than javax.validation.Validator).<br>
>><br>
>> At the moment all validation methods are hosted on javax.validation.Validator. Personally I don't see a strong reason for introducing<br>
>> another indirection/interface. Does anyone have objections removing the todo?<br>
><br>
> I guess Emmanuel does :)<br>
><br>
> Personally, I also used to be of the opinion that a separate interface<br>
> doesn't really add much value. What made me pondering though was the<br>
> recent discussion about adding new bean validation methods such as<br>
> validateProperty(T object, Path property, Class<?>... groups);<br>
><br>
> Following the interface segregation principle [1], it may indeed be a<br>
> good idea to have two separate interfaces, one for standard bean<br>
> validation and one for method validation. I think the main question<br>
> is, who the consumers of the individual methods are. I think there may<br>
> be a broader range of users of the bean validation methods<br>
> (validate(), validateProperty() etc.) than of the method validation<br>
> methods (validateParameters() etc.), which typically will only be<br>
> invoked by authors of integration/glue code. So for users of the first<br>
> group it would reduce complexity if the method validation stuff went<br>
> into a separate interface.<br>
><br>
> With respect to retrieving method validators, instead of something<br>
> like Validator#forMethod(Method method) etc. I could also imagine<br>
> ValidatorFactory#getMethodValidator(). Then one doesn't have to<br>
> retrieve a new validator for each validated method/constructor.<br>
<br>
+1 for ValidatorFactory#getMethodValidator() in case we decide separate interfaces<br>
<br>
<br>
--Hardy<br>
<br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</blockquote></div>
_______________________________________________<br>beanvalidation-dev mailing list<br><a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</blockquote></div><br></div></div></div><br>_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br></blockquote></div>