Re: [hibernate-dev] On possible extensions for the validator

Cross validation marker annotations like @ExactlyOneNull are not really actual constraints (ie annotated with @Constraint) because somehow they must carry two logic: - the property checking logic - the "aggregation" logic Besides these markers should be ignored by the rest of the Bean Validation execution (they don't mean anything in isolation). With that in mind I would say that: - we should logically forbid BV groups and cross validation groups to reuse the same interface to limit confusion. Ideally a different name for the two concepts would be better. - in practice, they live in different spaces BV constraints host BV groups and cross validation constraints host cross validation groups. They never interfere. So the iplmentation does not really care if the same interface is reused. By the way @CrossValidation can host BV groups as it's a regular constraint. Back to cross validation use cases, could we list 3 or 4 use cases of cross validations and what do we expect them to do (error report wise). That will help to define the generic mechanism to define cross validation markers and implementations, as it is today, it seems @ExactlyOneNull would be hardcoded. Frankly, I wonder if the cross validation solution will end up being more verbose than the raw class-level approach :)

On 18 oct. 2010, at 11:11, Hardy Ferentschik wrote: > 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(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev