[hibernate-dev] On possible extensions for the validator

Federico Mancini mancini_federico at yahoo.it
Mon Oct 18 08:30:38 EDT 2010


  Ok now I see it.
Using groups for cross-validation is a very nice solution to be able to 
reuse them on multiple sets of properties.
Then in Emmanuel's example I guess it should be

@AtLeastOneNotNullAmongst(groups={Group1.class,Group2.class})
B getB() { ... };

The @CrossValidation annotation at class level is definitely a good idea 
in order to avoid having a @CrossValidation marker inside
each cross-annotation, and it helps also the user/programmer to 
distinguish between normal and cross annotations in the code.
I am a bit concerned about how groups for cross-annotations and normal 
annotations would interact with each other.
Should it be possible to mix groups for normal and cross annotations 
when defining a @GroupSequence?
Can both an annotation and a cross annotation belong to the same group? 
If not, how to enforce that
  (by the given example, the validator cannot distinguish between 
cross-annotations and normal annotations, and therefore cannot perform 
any check.
Of course I am assuming that you don't want to use a @CrossAnnotation 
marker in the annotation declaration, or all of this would not be a 
problem at all) ?

I can think of two ways right now:
1) We might have the cross-annotations themselves defined at class-level 
rather than the groups. Like:

@Crossvalidations(CrossAnnotations={ExactlyOneNull.class,...})


In this way the validator (and the user) would know straight away which 
are cross annotations and which not, and groups could still be used in 
the same way at method level.

2.a) If a class defining a groups implemented some @interface Group" 
then one could create something like "CrossGroup extends Group" and have 
special groups reserved for cross-annotation:

@Crossvalidations(CrossGroups{BankAccount.class,ContactDetails.class})


The CrossGroup element in the annotation declaration would then work as 
an implicit marker, so that  annotations using those groups must be 
cross-annotations and normal annotations would not be able to use them.

2.b) There exists a default group for all cross-annotations



en 18.10.2010 11:11, skrev Hardy Ferentschik:
> I was also thinking about a generic class level @CrossValidation
> constraint. I think Emmanuel and I
> are thinking about the same thing here:
>
> @CrossValidations({
>      @CrossValidation(forGroup=BankAccount.class),
>      @CrossValidation(forGroup=ContactDetails.class)
> })
> public class BankAccountNumber {
>
>      @ExactlyOneNull(groups=BankAccount.class)
>      public String getIBAN() {
>         return IBAN;
>      }
>
>      @ExactlyOneNull(groups=BankAccount.class)
>      public String getAccount() {
>         return account;
>      }
>
>
>      @ExactlyOneNull(groups=ContactDetails.class)
>      public String getHomeNumber() {
>         return homeNumber;
>      }
>
>      @ExactlyOneNull(groups=ContactDetails.class)
>      public String getWorkNumber() {
>         return workNumber;
>      }
> }
>
> Using groups (or maybe payloads!?) you can have multiple cross validations
> of the same type within one entity.
>
> --Hardy
>
>
> On Mon, 18 Oct 2010 09:48:16 +0200, Emmanuel Bernard
> <emmanuel at hibernate.org>  wrote:
>
>> On 16 oct. 2010, at 10:56, Dag Hovland wrote:
>>
>>> On 15/10/10 13:33, Emmanuel Bernard wrote:
>>> (...)
>>>> That being said, I wonder whether you can write your approach atop a
>>>> generic class-level constraint @CrossValidation that would look for
>>>> the properties annotations and behave as expected. That would be a
>>>> nice way to offer both world to the users. You will need to "group"
>>>> cross field constraints though: as I see it on the paper, you can only
>>>> have one group of cross level constraint for a given constraint type
>>>> per class.
>>> I do not really understand this. Can you give an example?
>> class BrokenModel {
>>     @AtLeastOneNotNullAmongst(Group1.class)
>>     A getA() { ... };
>>     @AtLeastOneNotNullAmongst(Group1.class)
>> @AtLeastOneNotNullAmongst(Group2.class)
>>     B getB() { ... };
>>     @AtLeastOneNotNullAmongst(Group2.class)
>>     C getC() { ... };
>> }
>>
>> A or B must be not null and B or C must be not null.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>




More information about the hibernate-dev mailing list