[bv-dev] Representation of cross-parameter constraints

[Emmanuel Bernard]

Damn you and your getName(). Let's deprecate this method and be done
with it! ;)

On Mon 2013-02-11 19:45, Gunnar Morling wrote:
> 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
> >

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