Hi again, I was just wondering whether I should interpret the lack of answers as "no, this is not interesting at all", or as "we have a lot of other things to do and do not have time for this right now"? Federico Den 22.09.2010 09:08, skrev Federico Mancini: > Hi all, > I am new to the list and I am opening this thread on Emmanuel Bernard's > suggestion, in order to > discuss some possible extensions to the validator (jsr 303) I have been > working on with a couple of collegues. > Mainly it concerns the possibility to extend composition with boolean > operators (ex.: A field is either in the range 1-10 OR 20-30 AND > notNull) and allow validation of sets of interdependent properties > (ex.: EITHER the name field is notNull OR the surname field is notNull/ > AT LEAST 1 field must be filled/etc....). > > A description of the experimental framework we implemented can be found > here http://www.ii.uib.no/publikasjoner/texrap/pdf/2009-389.pdf , and > some further discussion on the choices we made here > http://www.ii.uib.no/~federico/papers/Annotations.pdf. > > I hope this might be of some interest for the Hybernate Validator > project, > but, even if not, it would be nice to get some feedback. > > Thanks, > Federico Mancini > _______________________________________________ > 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

Hi and thank you for your answer. I am aware that our work is extremely similar to the jsr 303, and that is exactly why I wanted to show it to you. It just happened that we independently developed similar solutions for the same problem, but when we saw the specs for the jsr 303, we realized that it would not make sense to continue since a much better version of the same thing was already up and going in Hibernate. However we have spent a good amount of time and effort on our validator, and it would be great if some of our ideas could be picked up by the Hibernate Validator rather than just watch them go to waste. Therefore I am very happy that you find some of it of interest, and of course I would like to get involved and contribute as I can. Unfortunatly I am not familiar with the Hibernate Validator code (I only read the jsr specs) or how you guys work, so I would not know where to start, but if you give my some time (I am also working on some other project right now) and guidelines I will be happy to help. Thanks again for the reply, Federico Den 05.10.2010 15:17, skrev Hardy Ferentschik: > Hi Frederico, > > sorry for the late reply. I finally had some time to read through your > paper. > I think there are strong similarities between you work and Hibernate > Validator or > more specific the Bean Validation specification (JSR 303). > > Property validation in the SHIP Validator is basically the same as in > Bean Validation. > And what you call cross-annotations would be a class level validator in > Bean Validation terms. > > Bean Validation also offers constraint composition similar to what is > described in your paper. > What Bean Validation does not offer is a boolean composition of the > constraints. Here conjunction of > constraints is always assumed. > > We are not able to do something like this: > > > @BoolTest(BoolType.OR) > @Null > @Max(10) > @Target({ METHOD, FIELD }) > @Retention(RUNTIME) > @Constraint(validatedBy = { }) > public @interface NullOrMax { > public abstract String message() default "foo"; > public abstract Class<?>[] groups() default { }; > public abstract Class<? extends Payload>[] payload() default { }; > @OverridesAttribute(constraint = Max.class, name = "value") > public abstract long max() > } > > Also the ability to validate a subset of all properties from within a > class level validator sounds interesting. > > We could implement these features as Hibernate Validator specific > extensions. > Are you interested in getting involved? > > > --Hardy > > > On Tue, 05 Oct 2010 09:48:15 +0200, Federico Mancini > <mancini_federico(a)yahoo.it&gt; wrote: > >> Hi again, >> I was just wondering whether I should interpret the lack of answers as >> "no, this is not interesting at all", or as "we have a lot of other >> things to do and do not have time for this right now"? >> >> Federico >> >> Den 22.09.2010 09:08, skrev Federico Mancini: >>> Hi all, >>> I am new to the list and I am opening this thread on Emmanuel >>> Bernard's >>> suggestion, in order to >>> discuss some possible extensions to the validator (jsr 303) I have >>> been >>> working on with a couple of collegues. >>> Mainly it concerns the possibility to extend composition with boolean >>> operators (ex.: A field is either in the range 1-10 OR 20-30 AND >>> notNull) and allow validation of sets of interdependent properties >>> (ex.: EITHER the name field is notNull OR the surname field is >>> notNull/ >>> AT LEAST 1 field must be filled/etc....). >>> >>> A description of the experimental framework we implemented can be >>> found >>> here http://www.ii.uib.no/publikasjoner/texrap/pdf/2009-389.pdf , and >>> some further discussion on the choices we made here >>> http://www.ii.uib.no/~federico/papers/Annotations.pdf. >>> >>> I hope this might be of some interest for the Hybernate Validator >>> project, >>> but, even if not, it would be nice to get some feedback. >>> >>> Thanks, >>> Federico Mancini >>> _______________________________________________ >>> 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 > >

Class level validation is something we had considered as well, but discarded it as we considered it in a way "cheating" in our settings. This because what actually happens, if I understood correctly, is that the whole object is passed to the validator, at which point it is possible to create a validator class that has access to all properties of the object to validate and therefore check any kind of interdependent constraints. This however at cost of reusability and flexibility, since such class level annotations can only be used on that specific class, and this could easily be replaced by an internal method in the object to validate, which can be called at validation time.

What we mean with cross-annotations is something much weaker. Only the values of the properties annotated with the same cross-annotation are passed to the validator, as a list, so that the validator does not know which value comes from which property. The disadvantage is that the set of properties to validate can only be seen as a list of values, and what can be checked is that a certain amount of them satisfies the contraint.

The advantage (which was our priority), is that normal validation annotations (on single fields and methods) can be reused and composed also to create cross-annotations, remaining independet of the class, and requiring to write less code.

So the question is: would cross-annotations still be interesting in a validator where we have class level validation, or would it be only redundant?

Hi all, I am new to the list and I am opening this thread on Emmanuel Bernard's suggestion, in order to discuss some possible extensions to the validator (jsr 303) I have been working on with a couple of collegues. Mainly it concerns the possibility to extend composition with boolean operators (ex.: A field is either in the range 1-10 OR 20-30 AND notNull) and allow validation of sets of interdependent properties (ex.: EITHER the name field is notNull OR the surname field is notNull/ AT LEAST 1 field must be filled/etc....). A description of the experimental framework we implemented can be found here http://www.ii.uib.no/publikasjoner/texrap/pdf/2009-389.pdf , and some further discussion on the choices we made here http://www.ii.uib.no/~federico/papers/Annotations.pdf. I hope this might be of some interest for the Hybernate Validator project, but, even if not, it would be nice to get some feedback. Thanks, Federico Mancini _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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?

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&gt; 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

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&lt;emmanuel(a)hibernate.org&gt; 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