Ah I knew we had been working on such a problem that that it
groups :) Let's open a specification issue and consider it for next
Note that the domain model could have use inheritance or composition
naturally enforce the presence or not of attributes depending on the
model / role. It probably would be cleaner but is not always possible on
existing domain models.
Yes, although I think even for newly created models it doesn't always make
sense to differentiate roles of an entity via sub-classing/delegation, e.g.
when the roles are dynamically retrieved from a database or similar.
On Thu 2013-06-06 23:23, Gunnar Morling wrote:
> 2013/6/6 Thang Le <thangmle(a)gmail.com>
> > Thanks, Emmanuel
> > Here is a use case right off from my current work. My system is
> > a set of devices. A device is modeled as a class named
> > This class has many attributes. One of them is 'model' which can be
> > value from a set of valid values: SD, TRANSNET, X710... An
> > 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'
> > to REMOTE, we relax certain constraints.
> > I've tried to use grouping feature of Bean Validation but it doesn't
> > 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
> > constraints for checking NotBlank. @ScriptAssert is no better than
> > your own custom constraint.
> Hi Thang,
> There is a solution if you don't mind using a feature specific to the BV
> reference implementation Hibernate Validator.
> There you can dynamically re-define the default group sequence of an
> dependening on its state. So you could assign the constraints to two
> groups, AccessPoint.class and Remote.class and return one or the other as
> default group, depending on the value of the "role" attribute.
> the details.
> Maybe we should consider to add something like this to the spec.
> > On Thu, Jun 6, 2013 at 1:55 PM, Emmanuel Bernard <
> >> Hello,
> >> You will have to dive into more concrete use cases. We did not add
> >> 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
> >> this. That's a bit less reusable but is more readable and could be
> >> a more type safe way (than an EL)
> >> - you can use constraints like Hibernate Validator's @ScriptAssert
> >> let's you write a free Groovy, EL, etc expression and be validated.
> >> Emmanuel
> >> 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
> >> constraints in value-driven manner. Could we add a new attribute
> >> 'executeCondition' to the constrain definition?
> >> take an EL expression. A bean validation framework would need to
> >> the expression set in this attribute. The corresponding constraint
> >> only gets executed when the expression set for 'executeCondition'
> >> satisfied at runtime.
> >> >
> >> > Let me know your thoughts on this suggestion.
> >> >
> >> > Thanks,
> >> > Thang
> >> > _______________________________________________
> >> > beanvalidation-dev mailing list
> >> > beanvalidation-dev(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev