<div dir="ltr">2013/1/14 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">After letting this idea rest for a while, I still like it.<br>
<br>
In the issue, you also proposed to go a step further and get rid of<br>
@CrossParameterConstraint altogether. I sort of remember not being keen<br>
on the idea to protect future evolutions on the type-safe<br>
cross-parameter way. Have you thought about it more? What is your<br>
opinion?<br></blockquote><div><br></div><div>Yes, I still like the idea of having only the @Constraint annotation for defining constraints, but one problem I see is that one can not specify different validators for return value arrays and method argument arrays in cases like this:</div>
<div><br></div><div> @MyCustomConstraint(validationAppliesTo = PARAMETERS)</div><div> public void foo(int p1, int p2) { ... }</div><div><br></div><div> @MyCustomConstraint(validationAppliesTo = <span style="font-family:arial,sans-serif;font-size:13px">ANNOTATED_ELEMENT</span>)<br>
</div><div> public Object[] bar() { ... }</div><div><br></div><div>With the different annotations @Constraint and @CrossParameterConstraint, two different validators (both parameterized with <MyCustomConstraint, Object[]>) could be specified here. Not sure, how relevant this is in reality, though.</div>
<div><br></div><div>An alternative would be to extend @Constraint to accommodate the specification of generic validator(s) and/or a cross-parameter validator:</div><div><br></div><div> public<span> </span>@interface<span> </span><span>Constraint</span><span> {</span></div>
<div> Class<? extends ConstraintValidator<?, ?>>[] validatedBy() default {};</div><div> Class<? <span>extends</span> ConstraintValidator<?, ?>> crossParameterValidatorType() default ConstraintValidator.class;</div>
<div> }</div><div><br></div><div>The same rules would apply, i.e. the constraint must have a "validationAppliesTo" attribute in case validators for both cases are specified.</div><div><br></div><div style>Thinking about Matt's IMPLICIT suggestion a bit more, I guess we could even limit the cases where the constraint user must actually set the "validationAppliesTo" attribute to those cases where it can't be inferred automatically:</div>
<div><br></div><div style> //"validationAppliesTo" not required, since method is void</div><div><div> @MyCustomConstraint</div><div> public void foo(int p1, int p2) { ... }</div></div><div><br></div><div style>
//not required, since method has no parameters</div><div><div> @MyCustomConstraint<br></div><div> public Object[] bar() { ... }</div></div><div><br></div><div style> //"validationAppliesTo" required if constraint has a (generic) validator for Baz and cross-param validator for Object[]</div>
<div> @MyCustomConstraint(validationAppliesTo = ANNOTATED_ELEMENT)<br></div><div style> public Baz foo(int p1, int p2) { ... }<br></div><div><p></p><div> //"validationAppliesTo" required if constraint has a (generic) validator for Object[] and cross-param validator for Object[]<br>
</div><div> @MyCustomConstraint(validationAppliesTo = PARAMETERS)<br></div><div> public Object[] foo(int p1, int p2) { ... }</div><div><br></div><div style>The ValidationTarget enum would have the values IMPLICIT (default), ANNOTATED_ELEMENT and PARAMETERS.</div>
<div style><br></div><div style>WDYT?</div><div style><br></div><div style>--Gunnar</div><p></p></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span><font color="#888888"><br>
Emmanuel<br>
</font></span><div><div><br>
On Mon 2013-01-07 23:21, Gunnar Morling wrote:<br>
> Hi all,<br>
><br>
> As per the latest spec draft, a constraint must be either a cross-parameter<br>
> *or* a generic constraint, but not both at the same time, as otherwise it<br>
> would be ambiguous whether a constraint on a method refers to the method<br>
> parameters or return value.<br>
><br>
> Most of the time this does not really pose a limitation, but some<br>
> constraints actually might be both, cross-parameter *and* generic,<br>
> depending on the specific context. Examples are @ScriptAssert in Hibernate<br>
> Validator or generic constraints such as this:<br>
><br>
> @EqualPasswords<br>
> public void register(String userName, String password, String<br>
> confirmedPassword) {<br>
> }<br>
><br>
> @EqualPasswords<br>
> public class ResetPasswordRequest {<br>
> String userName;<br>
> String password;<br>
> String confirmedPassword;<br>
> }<br>
><br>
> Based on a recent BVAL issue [1], I'm proposing to introduce a special<br>
> constraint annotation attribute, "validationAppliesTo", allowing to specify<br>
> the required behavior at the usage site:<br>
><br>
> @EqualPasswords(validationAppliesTo=PARAMETERS)<br>
> public void register(String username, String password, String<br>
> confirmPassword) {<br>
> }<br>
><br>
> @EqualPasswords(validationAppliesTo=ANNOTATED_ELEMENT)<br>
> public class ResetPasswordRequest {<br>
> String password;<br>
> String confirmedPassword;<br>
> }<br>
><br>
> The following rules would apply:<br>
><br>
> * If a constraint is annotated with @Constraint and<br>
> @CrossParameterConstraint, it must define a member "validationAppliesTo".<br>
> The default value should be ANNOTATED_ELEMENT.<br>
> * If a constraint is annotated with only one<br>
> of @Constraint/@CrossParameterConstraint, defining a "validationAppliesTo"<br>
> member doesn't have any special effect<br>
> * Specifying validationAppliesTo=PARAMETERS anywhere except a method causes<br>
> ConstraintDeclarationException<br>
><br>
> Any thoughts?<br>
><br>
> --Gunnar<br>
><br>
> [1] <a href="https://hibernate.onjira.com/browse/BVAL-340" target="_blank">https://hibernate.onjira.com/browse/BVAL-340</a><br>
<br>
</div></div><div><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>
<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>
</div></div></blockquote></div><br></div></div>