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(a)gmail.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

2013/6/6 Thang Le <thangmle(a)gmail.com&gt; > 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_sin... 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(a)hibernate.org&gt;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(a)gmail.com&gt; 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(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 > _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

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.

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.

Emmanuel On Thu 2013-06-06 23:23, Gunnar Morling wrote: > 2013/6/6 Thang Le <thangmle(a)gmail.com&gt; > > > 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_sin... > 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(a)hibernate.org&gt;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(a)gmail.com&gt; 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(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 > >