<div dir="ltr"><div><div><div>Thanks, Emmanuel<br><br></div>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.<br>
<br></div>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.<div class=""><div id=":1ba" class="" tabindex="0"><img class="" src="https://mail.google.com/mail/u/0/images/cleardot.gif"></div></div><span class=""><font color="#888888">Thang<br>
</font></span></div><div><span class=""><font color="#888888">
<br></font></span></div><span class=""></span><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 6, 2013 at 1:55 PM, Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
You will have to dive into more concrete use cases. We did not add such a feature so far for a few reasons:<br>
<br>
- 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.<br>
- 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)<br>
- you can use constraints like Hibernate Validator's @ScriptAssert that let's you write a free Groovy, EL, etc expression and be validated.<br>
<br>
Emmanuel<br>
<div><div class="h5"><br>
On 6 juin 2013, at 19:19, Thang Le <<a href="mailto:thangmle@gmail.com">thangmle@gmail.com</a>> wrote:<br>
<br>
> Hi all,<br>
><br>
> 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.<br>
><br>
> Let me know your thoughts on this suggestion.<br>
><br>
> Thanks,<br>
> Thang<br>
</div></div>> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</blockquote></div><br></div></div>