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

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