5:41 p.m.
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?
2012/12/5 Emmanuel Bernard <emmanuel(a)hibernate.org>
addNode(CLASS_LEVEL) is not a bad idea. The alternative is a full
method
as proposed in BVAL-191.
Unfortunately, we cannot solve the problem with this method because of
the second use case I describe in the email below. This example does not
work even if does not make use of addNode(null) :(
Emmanuel
On Wed 2012-12-05 14:10, Hardy Ferentschik wrote:
> Hi,
>
> 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).
> 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.
> Couldn't there be for example a constant so that you could do something
like addNode(CLASS_LEVEL). I find this much more telling.
> In this light option 4 - adding a different method - of your proposed
solution on http://beanvalidation.org/proposals/BVAL-221/ sounds more
appealing again.
> What about adding addClassLevelNode()?
>
> --Hardy
>
>
>
> On 4 Jan 2012, at 4:42 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
>
> > These are good questions
> >
> > ## Natural way to do it?
> >
> > Assuming
> >
> > @HasCorrectHomeAddressFromTop
> > class Order {
> > @HasCorrectHomeAddressFromUser
> > User user;
> > }
> >
> > class User {
> > @CollectionNotEmpty
> > @HasCorrectHomeAddressFromAddresses
> > Map<String,Address> addresses;
> > }
> >
> > When `HasCorrectHomeAddressFromTop` is validated, you can attach a
> > `ConstraintViolation` to Order.user.addresses["home"] with the
> > following call and it works in BV 1.0
> > This is how the API is supposed to be used.
> >
> > context.buildConstraintViolationWithTemplate( "Incorrect home
address" )
> > .addNode( "user" )
> > .addNode( "addresses" )
> > .inIterable().atKey( "home" )
> > .addConstraintViolation();
> >
> > following this logic, when `HasCorrectHomeAddressFromUser` is
validated,
> > you can attach a `ConstraintViolation` with the following call but that
> > does not work in BV 1.0.
> >
> > context.buildConstraintViolationWithTemplate( "Incorrect home
address" )
> > .addNode( "addresses" )
> > .inIterable().atKey( "home" )
> > .addConstraintViolation();
> >
> > When `HasCorrectHomeAddressFromAddresses` is validated, you can attach
a
> > `ConstraintViolation` with the following call but that does not work
> > in BV 1.0.
> >
> > context.buildConstraintViolationWithTemplate( "Incorrect home
address" )
> > .addNode( null )
> > .inIterable().atKey( "home" )
> > .addConstraintViolation();
> >
> > Not that we use null as we add a class level constraint violation to
the
> > element in `addresses["home"]`.
> >
> > For you info, when `CollectionNotEmpty` is validated, you can attach a
> > `ConstraintViolation` with the following call.
> >
> > context.buildConstraintViolationWithTemplate( "collection empty"
)
> > .addConstraintViolation();
> >
> > ## Loss in type-safety
> >
> > If we add `inIterable()` to `NodeBuilderDefinedContext` we solve our
> > problem but we introduce a leak in the type safety. I could do the
> > following calls
> >
> > context.buildConstraintViolationWithTemplate( "Incorrect home
address" )
> > .addNode( null )
> > .inIterable().atKey( "home" )
> > .inIterable().atKey( "wc" )
> > .addConstraintViolation();
> >
> > This call is not correct as no node has been (explicitly) created
> > between the two inIterable() calls. The correct call would be
> >
> > context.buildConstraintViolationWithTemplate( "Incorrect WC
location" )
> > .addNode( null )
> > .inIterable().atKey( "home" )
> > .addNode( null )
> > .inIterable().atKey( "wc" )
> > .addConstraintViolation();
> >
> > Here we are assuming that the `addresses` elements contain map.
> >
> > We could add in the spec that subsequent calls to `inIterable()`
> > implicitly create a node without name.
> >
> > The problem is not as critical as I imagined but that would require
> > adding some magic rules wrt node creation.
> >
> > Also imagine a user willing to validate a property of Address, could he
> > forget to call the node creation method?
> >
> > Emmanuel
> >
> > On Mon 2012-11-26 13:07, Hardy Ferentschik wrote:
> >>
> >> On 23 Jan 2012, at 2:48 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org>
wrote:
> >>
> >>> The question is do we want to do that or lean towards one of the
> >>> alternative methods:
> >>>
> >>> - an explicit new method deprecating addNode
> >>> - relaxing NodeBuilderDefinedContext and adding the new contract on
it
> >>
> >> In the proposal you are saying about relaxing
NodeBuilderDefinedContext: "But that would break the contextual
> >> and safety of the API as this interface is also returned by atKey and
atIndex."
> >> Can you provide an example?
> >>
> >> Also in the proposal you are saying that:
> >>
> >> context.buildConstraintViolationWithTemplate("oh noes")
> >> .addNode(null) //ie the contained element
> >> inIterable().atKey(someKey)
> >> .addConstraintViolation();
> >>
> >> would be the natural solution. Why is ".addNode(null)" natural
and
why could we not have inIterable() directly
> >> on ConstraintViolationBuilder?
> >>
> >> --Hardy
> >>
> >>
> >> _______________________________________________
> >> 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