[hibernate-dev] HV-274 - Write a programmatic mapping API for constraint declarations

[Hardy Ferentschik]

On Thu, 20 May 2010 23:49:00 +0200, Gunnar Morling  
<gunnar.morling at googlemail.com> wrote:


> personally I feel that the proposed definition classes bring quite a  
> large (conceptual and technical) overhead to the table. Writing them  
> from hand
> isn't really cool, building an AP for this OTOH seems a lot of work for  
> this feature which I think might have not that much users.

True, this feature might not have too many users, but we have to see the  
overhead from
a user's perspective and not from ours.
The effort to implement the current solution lies somewhere between the  
fully types
version  
(config.type(ShoppingCart.class).getter("items").size().max(30).notNull())
and the completely "untyped" one. As a bonus the required definition  
classes could
be generated via an annotation processor. Given what we have learned so  
far with
annotation processors it should not be too hard to write one.

By introducing a package org.hibernate.validator.cfg and the
ConstraintMapping class the conceptual overhead is isolated and the
integration into the core validator framework was not too
hard. Not much different than adding xml configured constraints.

> What do you think about the proposal I added as comment to the JIRA  
> issue?
> It allows to reference each constraint's attributes in a safe manner  
> without the need for additional definition classes.

True, we don't have to create any new classes within the framework, but to  
use the
API you have to create constraint instances which makes the API not really  
fluent
in the same way as the other APIs we recently introduced.
That said, I am not the big fluent API proponent. There are other team  
members who
stand for that ;-)

> The thing is actually I'm not sure, what use cases this API will have. I
> doubt someone would really use it by hand (as annotations are much  
> simpler).

I see the biggest usecase in testing, but as you mention code generation  
is an option as
well.


> Slightly OT, but what I really *would* like is an AP/some other tool for
> generating property definitions for arbitrary POJ(O|I)s ("property
> literals"). Allowing bean properties to be accessed in a safe way seems
> useful in many scenarios (besides the use case here, for data binding in
> GUIs for instance). I'm thinking about to build such a tool, if I only  
> had more time for these things :-)

I see the use cases as well, but this is not the job of an annotation  
processor, since
you want to create meta class for all pojos (independent of annotations).  
Sounds more like
a build (maven) plugin.

Personally I am still not sure if we take this whole type-safety thing not  
too far.

--Hardy



>
> 2010/5/20 Hardy Ferentschik <hibernate at ferentschik.de>
>
>> Hi,
>>
>> The approach is looking somewhat like this:
>>
>>
>> config
>>  .type(ShoppingCart.class)
>>    .getter("items")
>>      .constraint(NotNullDefinition.class)
>>      .constraint(SizeDefinition.class)
>>        .min(3).max(10);
>>    .getter("price")
>>      .constraint(RangeDefinition.class)
>>        .min(0)
>>        .max(100)
>>
>>
>> Instead of getter it will be property. Here is a running example:
>>
>>
>>                ConstraintMapping mapping = new ConstraintMapping();
>>                mapping.type( Marathon.class )
>>                                .property( "name", METHOD )
>>                                .constraint( NotNullDefinition.class )
>>                                .property( "numberOfRunners", FIELD )
>>                                .constraint( MinDefinition.class  
>> ).value( 1
>> );
>>
>>
>> Check the classes in org.hibernate.validator.cfg. I checked in some  
>> initial
>> work.
>> Not everything is wired up though. Feel free to send me some feedback.
>> Work is still in progress. One idea I had is to generate the  
>> XYZDefinition
>> classes via
>> an annotation processor ;-) Not sure if this is happening now or if I in
>> the first cut just
>> add the definition classes for the builtin constraints.
>>
>> --Hardy