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

[Thang Le]

That's great! 'GroupSequenceProvider' is all I need (the ability to
dynamically select/control constraints to be executed). Thanks, Gunnar.

Thang


On Thu, Jun 6, 2013 at 5:23 PM, Gunnar Morling <gunnar at hibernate.org> 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
>>
>
>
> _______________________________________________
> 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/20130606/c5786032/attachment-0001.html