Here is a use case right off from my current work. My system is monitoring
a set of devices. A device is modeled as a class named AuthorizedDevice.
This class has many attributes. One of them is 'model' which can be any
value from a set of valid values: SD, TRANSNET, X710... An AuthorizedDevice
also has an attribute called 'role' which can be either REMOTE or
ACCESSPOINT. Based on the value set for 'model' & 'role', we either do
relax specific constraints on some attributes. For example: if an
AuthorizedDevice has its 'role' set to ACCESSPOINT, we require certain
attributes must not be blank. While an AuthorizedDevice has its 'role' set
to REMOTE, we relax certain constraints.
I've tried to use grouping feature of Bean Validation but it doesn't seem
to help in achieving the my goal. I agree we can always write custom
constraints but that means I can't reuse the built-in validation
constraints from the framework (not even in the case of writing a
constraint composition). And certainly, I would not want to write a custom
constraints for checking NotBlank. @ScriptAssert is no better than writing
your own custom constraint.
On Thu, Jun 6, 2013 at 1:55 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
You will have to dive into more concrete use cases. We did not add such a
feature so far for a few reasons:
- groups are offering a way to validate specific subset of constraints and
solve a good chunk of non static use cases as you put it.
- you can write a custom constraint (property or class level) to achieve
this. That's a bit less reusable but is more readable and could be done in
a more type safe way (than an EL)
- you can use constraints like Hibernate Validator's @ScriptAssert that
let's you write a free Groovy, EL, etc expression and be validated.
On 6 juin 2013, at 19:19, Thang Le <thangmle(a)gmail.com> wrote:
> Hi all,
> Validation constraints defined in Bean Validation 1.1 are mostly written
and assigned in static manner. This limits us to reuse the existing
constraints in value-driven manner. Could we add a new attribute
'executeCondition' to the constrain definition? 'executeCondition' would
take an EL expression. A bean validation framework would need to evaluate
the expression set in this attribute. The corresponding constraint logic
only gets executed when the expression set for 'executeCondition' is
satisfied at runtime.
> Let me know your thoughts on this suggestion.
> beanvalidation-dev mailing list