[bv-dev] Representation of cross-parameter constraints

[Gunnar Morling]

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 at 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 at 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
>>
>> [1] https://hibernate.onjira.com/browse/BVAL-370
>>
>> _______________________________________________
>> 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/20130211/c0d6e682/attachment.html