[bv-dev] Node#getElementDescriptor() for user-created nodes

[Emmanuel Bernard]

At this time of day I do tend to like option #1 (ie making virtual nodes
illegal). Otherwise my preferred option is #4
(VirtualElementDescriptor).

Out of curiosity for people not preferring option #1. What use case do
you see in having virtual nodes?

Emmanuel

On Fri 2013-02-08 11:08, Matt Benson wrote:
> Hmm, a third option for the elementClass of such a descriptor might be
> Void.class.
> 
> I prefer option #3, followed by #4.
> 
> Matt
> 
> 
> On Fri, Feb 8, 2013 at 5:17 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> > Hi experts,
> >
> > One of the remaining issues on our way to 1.1 is BVAL-336 [1], which is
> > about what to return from Node#getElementDescriptor() for nodes added by
> > the user via the ConstraintViolationBuilder API.
> >
> > Note that as per the spec only sub paths can be created by the user, i.e.
> > user added nodes always represent properties but e.g. no methods or
> > parameters. Based on that, it seems right to return the correct
> > PropertyDescriptor in case a user adds a node for an existing property.
> >
> > Things get tricky though when nodes are added for non-existent properties.
> > Emmanuel, Hardy and I identified the following options to address this
> > situation:
> >
> > #1 Disallow adding non-existent nodes
> >
> > In case a user adds a node but no property with that names exist, an
> > exception is thrown. The problem is elegantly avoided that way, but we
> > might break some 1.0 user code (currently the spec is not really clear
> > whether added nodes must exist or not).
> >
> > #2 return null from getElementDescriptor()
> >
> > When invoking getElementDescriptor() on a Node representing a non-existent
> > property, null could be returned. This seems consistent (there is no
> > element), but causes additional null checking when traversing a path.
> >
> > #3 return a PropertyDescriptor from getElementDescriptor()
> >
> > Since all user-added nodes represent properties, a PropertyDescriptor
> > could be returned. hasConstraints() would return false,
> > getConstraintDescriptors() the empty set etc. This would allow to handle
> > all nodes and their descriptors uniformly when traversing a path. Question
> > is what to return from PropertyDescriptor#getElementClass(). Options are to
> > return null (signaling that the property is non-existent) or Object.class.
> >
> > #4 return a VirtualDescriptor from getElementDescriptor()
> >
> > We could create a new Kind, VIRTUAL, and an accompanying type
> > VirtualDescriptor and return an instance of this. Behavior of the methods
> > on the descriptor would be basically the same as in #3; getKind() returning
> > Kind.VIRTUAL would allow for a very explicit checking whether the node
> > exists or not.
> >
> > Any feedback on the options (ideally with arguments pro/con) or other
> > alternatives are highly welcome. As life goes, Emmanuel's, Hardy's and my
> > preferences are equally distributed between these options :)
> >
> > Thanks,
> >
> > --Gunnar
> >
> > [1] https://hibernate.onjira.com/browse/BVAL-336
> >
> >
> > _______________________________________________
> > 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