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

Personally my reason for eschewing option #1 is the possibility of breaking existing code. Matt On Fri, Feb 8, 2013 at 11:22 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt;wrote: > 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(a)hibernate.org&gt; > 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(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > > > _______________________________________________ > > beanvalidation-dev mailing list > > beanvalidation-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >

_______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev