> we managed to implement a first version of boolean composition for the > validator, and it seems to require very few changes to the code.
Nice :) > We also opened an issue on Jira about that. I added some comments to http://opensource.atlassian.com/projects/hibernate/browse/HV-390 If you want to get some feedback regarding the code I suggest you attach a patch to the issue or you use the new possibilities we have now through the move to git (http://github.com/hibernate/hibernate-validator) by forking the validator repo. > From the tests we ran, the constraints seem to be evaluated correctly, > but we have some strange behaviour regarding the reporting of > violations, which we are investigating. > Reporting violations would also be an interesting subject of discussion > in itself, since we cannot say anymore that a composed constraint fails > if just one of the constraint > composing it fails. We have to evaluate all the tree of constraints > before knowing the final outcome (if it is a disjunction for example). > In this case we thought it might be best to report everything as a > single violation by default. I think the composing constraint needs still to honor things like @ReportAsSingleViolation. In case of a disjunction - if all validation fails I think you should get the violation errors for all of them (unless @ReportAsSingleViolation is used). As soon as one validation succeeds you don't get any validation error. > Another thing we wondered about is the default behaviour of built-in > constraints when they validate null values. Are they supposed to succeed > on null values by default? That's a suggestion by the Bean Validation Specification. The spec says: "While not mandatory, it is considered a good practice to split the core constraint validation from the not null constraint validation (for example, an @Email constraint will return true on a null object, i.e. will not take care of the @NotNull validation) null can have multiple meanings but is commonly used to express that a value does not make sense, is not available or is simply unknown. Those constraints on the value are orthogonal in most cases to other constraints. For example a String, if present, must be an email but can be null. Separating both concerns is a good practice." --Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
