[
http://opensource.atlassian.com/projects/hibernate/browse/HV-390?page=com...
]
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"),@Pattern(regexp="pat2"),@Pattern(regexp="pat3"),@Pattern(regexp="pat4")})
@interface WhiteList{..}
{code}
{code}
//Specify that none of the patterns must match
@Bool(ALLFALSE)
@List({@Pattern(regexp="pat1"),@Pattern(regexp="pat2"),@Pattern(regexp="pat3"),@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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira