Ah, I forgot one thing: Everyone voting for a separate descriptor/node representing cross-param elements must make a suggestion for a name for the new element type and for what to return from Node#getName() ;-)

Am 11.02.2013 16:34 schrieb "Matt Benson" <mbenson@apache.org>:
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.

$0.02,
Matt


On Mon, Feb 11, 2013 at 8:10 AM, Gunnar Morling <gunnar@hibernate.org> wrote:
Hi all,

Could you give us your feedback on BVAL-370 [1]?

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().

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.

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.

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).

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.

Any thoughts?

Thanks,

--Gunnar


_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev