Re: [hibernate-dev] [HV] Changes to API for programmatic constraint definition
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