[
http://opensource.atlassian.com/projects/hibernate/browse/HV-390?page=com...
]
Federico Mancini commented on HV-390:
-------------------------------------
We do not want to exclude it, we would like to have it as well, but we just noticed that
it does not seem to work with {{ALL_FALSE}}, and probably {{OR}} as well.
I had a suspect that such constraints are treated differently than the other composing
ones, and we tested it to make sure.
I should examine better the code, but I think that it is because the local validator (in
the example {{ComposedConstraintValidator.class}}) is not treated as a child of
{{ComposedConstraint}} in the annotation tree representing this annotation, but it is
checked independently by {{validateSingleConstraint()}} in the class {{ConstrintTree}}, as
if an annotation with children cannot have its own validator.
This of course does not make difference with {{@ConstraintComposition(AND)}}, since the
order in which constraints are checked is
unimportant in a conjunction, but for boolean evaluation purpouses, it should be treated
as a child and not an independent constraint.
From a quick test, it seems like it is enough to move the call to
{{validateSingleConstraint()}} so that its result is counted with the violations caused by
the children in the first loop of {{validateConstraints()}}.
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: booltest.zip, 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