[hibernate-issues] [Hibernate-JIRA] Commented: (HV-390) Boolean composition of constraints

[Federico Mancini (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HV-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=38785#action_38785 ] 

Federico Mancini commented on HV-390:
-------------------------------------

We have not tested {{ALLFALSE}} (probably ALL_FALSE rather than NOT) properly yet, but it should be well defined in the sense that it contributes correctly to the constraint evaluation. For simplicity, at the moment everything is reported just as a {{@ReportAsSingleViolation}} was present in the top level annotation (so that only the overall composed test is reported to  fail). The problem is that if the boolean constraint is very nested, error messages on single annotations might be meaningless in itself, without
considering where the annotation is in the "boolean path". That is why we wanted to discuss this with you before implementing some more advanced solution for this.

The current proposal is therefore that:
1) For {{AND}} nothing changes.
2) For {{OR}} I understand that you would like us to report ALL tests that fail, when the OR itself fails, or nothing otherwise.
3) For {{ALLFASE}} we should report ALL the ones that are true, when ALLFALSE fails.




> Boolean composition of constraints
> ----------------------------------
>
>                 Key: HV-390
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-390
>             Project: Hibernate Validator
>          Issue Type: New Feature
>          Components: engine
>            Reporter: Federico Mancini
>            Assignee: Hardy Ferentschik
>             Fix For: 4.2.0
>
>         Attachments: modified classes.zip
>
>
> By adding a built-in annotation @Bool (or some other name) with element values OR, ALLFALSE and AND (which would be the default) it would be possible to 
> compose constraints in a boolean fashion.
> For example:
> {code}
> //Specify that at least one of the patterns must match
> @Bool(OR)
> @List({@Pattern(regexp="pat1"), at Pattern(regexp="pat2"), at Pattern(regexp="pat3"), at Pattern(regexp="pat4")})
> @interface WhiteList{..}
> {code}
> {code}
> //Specify that none of the patterns must match
> @Bool(ALLFALSE)
> @List({@Pattern(regexp="pat1"), at Pattern(regexp="pat2"), at Pattern(regexp="pat3"), at Pattern(regexp="pat4")})
> @interface BlackList{..}
> {code}
> {code}
> //At least on valid contact method must match
> @Bool(OR)
> @Email
> @Address
> @Phone
> @interface ContactDetails{...}
> {code}
> This would greatly increase the type of new constraints that can be defined just by reusing some existing ones.
> Possible extensions might be for example further operators like XOR (meaning exactly one of the constraints must hold) or similar.
> It seems like it is possible to implement this feature by adding very little code to just a couple of classes, and adding the new @Bool annotation to the API.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira