[hibernate-issues] [Hibernate-JIRA] Commented: (HV-390) Boolean composition of constraints
[
http://opensource.atlassian.com/projects/hibernate/browse/HV-390?page=com...
]
Federico Mancini commented on HV-390:
-------------------------------------
Yes, violation reporting with boolean constraints is a pain. I understand what you mean
with {{ALL_FALSE}}. It is not easy to come up with meaningful default messages, especially
when a constraint should be reported as failed even if it actually succeeded. How do you
use the customized error message in this case? That is why our first instinct was to just
hide the complexity of the boolean tree defined by a composed annotation behind a default
@ReportAsSingleViolation.
The problem as I see it is mainly that, as long as you allow only {{AND}}, you don't
really have a constraint tree to evaluate, but a list. Whenever a single constraint fails,
you can stop and say that there is a violation. No matter how nested the contraint was in
the composed annotation.
That is, such composed annotations, do not really define new constraints, they are only a
container. That is why it makes sense to want to report the single violations form inside
the container: because their individual meaning is preserved, just as they where written
individually on the property to validate.
When instroducing boolean operators, you have to evaluate the constraints in a tree-like
fashion, and it makes a difference where the constraints that fails is in the tree.
In this case you are really defining a new constraint with a new meaning, where its
composing parts do not make much sense alone.
If some user really still wants to see a list of all composing constraints that caused the
violation, I can suggest we try to report the violations in a tree structure mirroring the
way the constraints are composed.
In this way the violations would be grouped by boolean operator, and a meaningful message
could be given for each subtree.
The user could then decide how many levels of this tree he would want to be reported or
shown, since I think the context in which a constraint fails is as important as the
constraint itself.
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