<div dir="ltr"><div>I do find the symmetry of the CrossParameterDescriptor attractive. As for the ExecutableDescriptor#getConstraints() question, I would agree that your suggestion to extend the ConstraintFinder API is probably more sensible than any other approach I can think of.<br>
<br>$0.02,<br></div>Matt<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 11, 2013 at 8:10 AM, Gunnar Morling <span dir="ltr"><<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>Could you give us your feedback on BVAL-370 [1]?</div><div><br></div><div>This is about how cross-parameter constraints should be represented in the metadata and other APIs. Currently, cross-parameter constraints are represented directly on the ExecutableDescriptor, contrary to parameter and return value constraints, which are reachable via ExecutableDescriptor#getParameterDescriptors() and getReturnValueDescriptor().</div>
<div><br></div><div>A similar question arises when building property paths for cross-parameter constraints. This is currently still undefined in the spec; The RI adds one node representing the hosting executable, while another node is added for parameter and return value violations.</div>
<div><br></div><div>The same with XML descriptors, where <cross-parameter-constraint> element(s) are directly added to the method/constructor element, as opposed to parameter/return value constraints which are added to the <parameter>/<return-value> sub-elements.</div>
<div><br></div><div>The question is, whether we should add such an intermediary descriptor/node also for cross-parameter constraints, e.g. ExecutableDescriptor#getCrossParameterDescriptor(). This would make the API more regular (all executable descriptors/constraints are retrieved by stepping one level down into the model), possibly helping to avoid confusions. By introducing an element CROSS_PARAMETER, also cross-parameter path nodes can be recognized very explicitly (today this is indicated by Kind.METHOD/CONSTRUCTOR on the leaf node).</div>
<div><br></div><div>On the other hand this is technically not strictly required (all information can be retrieved unambiguously from the current API). Also would be the question what to return from e.g. ExecutableDescriptor#getConstraints() (which currently is re-defined to return cross-param constraints only). One possibility would be to consider all executable constraints and extend the constraint finder API to allow filtering by ElementDescriptor.Kind.</div>
<div><br></div><div>Any thoughts?</div><div><br></div><div>Thanks,</div><div><br></div><div>--Gunnar</div><div><br></div><div>[1] <a href="https://hibernate.onjira.com/browse/BVAL-370" target="_blank">https://hibernate.onjira.com/browse/BVAL-370</a></div>
</div>
<br>_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">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>