<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Yes it would. That was my question earlier in this thread. Do we consider the intersection trick acceptable in the specification. <br><br>On 7 déc. 2012, at 00:41, Gunnar Morling <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br><br></div><blockquote type="cite"><div>Regarding BVAL-221, wouldn't that be fixed by the intersection type approach I suggested? Or do you think it we shouldn't pursue it because its too magic or uncommon?<br><div class="gmail_extra"><br><br><div class="gmail_quote">
2012/12/5 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
addNode(CLASS_LEVEL) is not a bad idea. The alternative is a full method<br>
as proposed in BVAL-191.<br>
<br>
Unfortunately, we cannot solve the problem with this method because of<br>
the second use case I describe in the email below. This example does not<br>
work even if does not make use of addNode(null) :(<br>
<span class="HOEnZb"><font color="#888888"><br>
Emmanuel<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed 2012-12-05 14:10, Hardy Ferentschik wrote:<br>
> Hi,<br>
><br>
> Thanks for the clarification. Indeed I was forgetting about the special meaning of null in this case (should have read section 5.2 of the spec).<br>
> In this context adding addNode(null) is indeed "natural" in the sense that it strictly follows the spec. That said, it still looks awkward to me.<br>
> Couldn't there be for example a constant so that you could do something like addNode(CLASS_LEVEL). I find this much more telling.<br>
> In this light option 4 - adding a different method - of your proposed solution on <a href="http://beanvalidation.org/proposals/BVAL-221/" target="_blank">http://beanvalidation.org/proposals/BVAL-221/</a> sounds more appealing again.<br>
> What about adding addClassLevelNode()?<br>
><br>
> --Hardy<br>
><br>
><br>
><br>
> On 4 Jan 2012, at 4:42 PM, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br>
><br>
> > These are good questions<br>
> ><br>
> > ## Natural way to do it?<br>
> ><br>
> > Assuming<br>
> ><br>
> > @HasCorrectHomeAddressFromTop<br>
> > class Order {<br>
> > @HasCorrectHomeAddressFromUser<br>
> > User user;<br>
> > }<br>
> ><br>
> > class User {<br>
> > @CollectionNotEmpty<br>
> > @HasCorrectHomeAddressFromAddresses<br>
> > Map<String,Address> addresses;<br>
> > }<br>
> ><br>
> > When `HasCorrectHomeAddressFromTop` is validated, you can attach a<br>
> > `ConstraintViolation` to Order.user.addresses["home"] with the<br>
> > following call and it works in BV 1.0<br>
> > This is how the API is supposed to be used.<br>
> ><br>
> > context.buildConstraintViolationWithTemplate( "Incorrect home address" )<br>
> > .addNode( "user" )<br>
> > .addNode( "addresses" )<br>
> > .inIterable().atKey( "home" )<br>
> > .addConstraintViolation();<br>
> ><br>
> > following this logic, when `HasCorrectHomeAddressFromUser` is validated,<br>
> > you can attach a `ConstraintViolation` with the following call but that<br>
> > does not work in BV 1.0.<br>
> ><br>
> > context.buildConstraintViolationWithTemplate( "Incorrect home address" )<br>
> > .addNode( "addresses" )<br>
> > .inIterable().atKey( "home" )<br>
> > .addConstraintViolation();<br>
> ><br>
> > When `HasCorrectHomeAddressFromAddresses` is validated, you can attach a<br>
> > `ConstraintViolation` with the following call but that does not work<br>
> > in BV 1.0.<br>
> ><br>
> > context.buildConstraintViolationWithTemplate( "Incorrect home address" )<br>
> > .addNode( null )<br>
> > .inIterable().atKey( "home" )<br>
> > .addConstraintViolation();<br>
> ><br>
> > Not that we use null as we add a class level constraint violation to the<br>
> > element in `addresses["home"]`.<br>
> ><br>
> > For you info, when `CollectionNotEmpty` is validated, you can attach a<br>
> > `ConstraintViolation` with the following call.<br>
> ><br>
> > context.buildConstraintViolationWithTemplate( "collection empty" )<br>
> > .addConstraintViolation();<br>
> ><br>
> > ## Loss in type-safety<br>
> ><br>
> > If we add `inIterable()` to `NodeBuilderDefinedContext` we solve our<br>
> > problem but we introduce a leak in the type safety. I could do the<br>
> > following calls<br>
> ><br>
> > context.buildConstraintViolationWithTemplate( "Incorrect home address" )<br>
> > .addNode( null )<br>
> > .inIterable().atKey( "home" )<br>
> > .inIterable().atKey( "wc" )<br>
> > .addConstraintViolation();<br>
> ><br>
> > This call is not correct as no node has been (explicitly) created<br>
> > between the two inIterable() calls. The correct call would be<br>
> ><br>
> > context.buildConstraintViolationWithTemplate( "Incorrect WC location" )<br>
> > .addNode( null )<br>
> > .inIterable().atKey( "home" )<br>
> > .addNode( null )<br>
> > .inIterable().atKey( "wc" )<br>
> > .addConstraintViolation();<br>
> ><br>
> > Here we are assuming that the `addresses` elements contain map.<br>
> ><br>
> > We could add in the spec that subsequent calls to `inIterable()`<br>
> > implicitly create a node without name.<br>
> ><br>
> > The problem is not as critical as I imagined but that would require<br>
> > adding some magic rules wrt node creation.<br>
> ><br>
> > Also imagine a user willing to validate a property of Address, could he<br>
> > forget to call the node creation method?<br>
> ><br>
> > Emmanuel<br>
> ><br>
> > On Mon 2012-11-26 13:07, Hardy Ferentschik wrote:<br>
> >><br>
> >> On 23 Jan 2012, at 2:48 PM, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br>
> >><br>
> >>> The question is do we want to do that or lean towards one of the<br>
> >>> alternative methods:<br>
> >>><br>
> >>> - an explicit new method deprecating addNode<br>
> >>> - relaxing NodeBuilderDefinedContext and adding the new contract on it<br>
> >><br>
> >> In the proposal you are saying about relaxing NodeBuilderDefinedContext: "But that would break the contextual<br>
> >> and safety of the API as this interface is also returned by atKey and atIndex."<br>
> >> Can you provide an example?<br>
> >><br>
> >> Also in the proposal you are saying that:<br>
> >><br>
> >> context.buildConstraintViolationWithTemplate("oh noes")<br>
> >> .addNode(null) //ie the contained element<br>
> >> inIterable().atKey(someKey)<br>
> >> .addConstraintViolation();<br>
> >><br>
> >> would be the natural solution. Why is ".addNode(null)" natural and why could we not have inIterable() directly<br>
> >> on ConstraintViolationBuilder?<br>
> >><br>
> >> --Hardy<br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> beanvalidation-dev mailing list<br>
> >> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> > _______________________________________________<br>
> > beanvalidation-dev mailing list<br>
> > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>beanvalidation-dev mailing list</span><br><span><a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a></span><br></div></blockquote></body></html>