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
