[bv-dev] Data-driven execution for validation constraints

[Gunnar Morling]

2013/6/7 Emmanuel Bernard <emmanuel at hibernate.org>

> Ah I knew we had been working on such a problem that that it involved
> groups :) Let's open a specification issue and consider it for next
> round.
>

There you go: https://hibernate.atlassian.net/browse/BVAL-457


> Note that the domain model could have use inheritance or composition to
> 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.


> Emmanuel
>
> On Thu 2013-06-06 23:23, Gunnar Morling wrote:
> > 2013/6/6 Thang Le <thangmle at gmail.com>
> >
> > > Thanks, Emmanuel
> > >
> > > 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
> or
> > > 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.
> > >
> >
> > 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
> object
> > 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.
> >
> http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#d0e2886has
> > the details.
> >
> > Maybe we should consider to add something like this to the spec.
> >
> > --Gunnar
> >
> > Thang
> > >
> > >
> > >
> > > On Thu, Jun 6, 2013 at 1:55 PM, Emmanuel Bernard <
> emmanuel at hibernate.org>wrote:
> > >
> > >> Hello,
> > >>
> > >> 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.
> > >>
> > >> Emmanuel
> > >>
> > >> On 6 juin 2013, at 19:19, Thang Le <thangmle at 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.
> > >> >
> > >> > Thanks,
> > >> > Thang
> > >> > _______________________________________________
> > >> > beanvalidation-dev mailing list
> > >> > beanvalidation-dev at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >>
> > >
> > >
> > > _______________________________________________
> > > beanvalidation-dev mailing list
> > > beanvalidation-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20130610/35ddc2d0/attachment.html