[hibernate-dev] [HV] Changes to API for programmatic constraint definition

[Hardy Ferentschik]

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