Hi guys, First, sorry for this late response.
I think too that there is no solution to keep the single invocation chain and the grouping approach. IMHO, avoid the misuse of the API is more important than keeping the single invocation chain. Regarding https://gist.github.com/940438, I really prefer the last one. ConstraintMapping mapping = new ConstraintMapping(); mapping.type( Marathon.class ) .constraint( ConstraintDef.createGeneric( MarathonConstraint.class ).param( "minRunner", 1 ) ) .property( "name", METHOD ) .constraint( ConstraintDef.create(SizeDef.class).message( "name too short" ).min( 3 ) ) .constraint( ConstraintDef.create(NotNullDef.class ) .property( "numberOfHelpers", FIELD ) .constraint( ConstraintDef.create(MinDef.class).value( 1 ) ); The use of ConstraintDef class as a single entry point for constraint creations unifies how generic and "normal" constraints are created. --Kevin On lundi 2 mai 2011 at 06:03, Hardy Ferentschik wrote: Hi, > > Great summary Gunnar :-) > I also thought about the API for quite some time and could not find > a solution keeping the current "grouping" and the single invocation chain > w/o introducing cases for invalid usages. > Initially I thought about keeping these inconsistencies for the sake > of keeping the current API and throw an exception at runtime, but looking > at your suggestions I think we can offer a solution which is correct w/o > loosing much of the fluent API. > > I like the last version in this gist best - > https://gist.github.com/940438 : > > > ConstraintMapping mapping = new ConstraintMapping(); > mapping.type( Marathon.class ) > .constraint( ConstraintDef.createGeneric( MarathonConstraint.class ) > .param( "minRunner", 1 ) ) > .property( "name", METHOD ) > .constraint( ConstraintDef.create(SizeDef.class).message( "name > too short" ).min( 3 ) ) > .constraint( ConstraintDef.create(NotNullDef.class ) > .property( "numberOfHelpers", FIELD ) > .constraint( ConstraintDef.create(MinDef.class).value( 1 ) ); > > > > Another question is whether we should enforce an order within the > > constraint definitions for one type (e.g. class-level -> properties -> > > method 1 parameters -> method 1 return value -> method 2 ...) or allow > > an arbitrary order here. Personally I don't see the need for such an > > order (we don't require one implementation-wise, and users could > > adhere to one by convention if they want to), but Hardy and Kevin feel > > different about this :) > > I still like the idea, especially since it also differentiates between > standard > Bean Validation validation and the method level validation extension. > > --Hardy > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
