<div dir="ltr">2013/6/7 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Ah I knew we had been working on such a problem that that it involved<br>
groups :) Let's open a specification issue and consider it for next<br>
round.<br></blockquote><div><br></div><div style>There you go: <a href="https://hibernate.atlassian.net/browse/BVAL-457">https://hibernate.atlassian.net/browse/BVAL-457</a></div><div style>�</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Note that the domain model could have use inheritance or composition to<br>
naturally enforce the presence or not of attributes depending on the<br>
model / role. It probably would be cleaner but is not always possible on<br>
existing domain models.<br></blockquote><div><br></div><div style>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.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
Emmanuel<br>
</font></span><div class=""><div class="h5"><br>
On Thu 2013-06-06 23:23, Gunnar Morling wrote:<br>
> 2013/6/6 Thang Le <<a href="mailto:thangmle@gmail.com">thangmle@gmail.com</a>><br>
><br>
> > Thanks, Emmanuel<br>
> ><br>
> > Here is a use case right off from my current work. My system is monitoring<br>
> > a set of devices. A device is modeled as a class named AuthorizedDevice.<br>
> > This class has many attributes. One of them is 'model' which can be any<br>
> > value from a set of valid values: SD, TRANSNET, X710... An AuthorizedDevice<br>
> > also has an attribute called 'role' which can be either REMOTE or<br>
> > ACCESSPOINT. Based on the value set for 'model' & 'role', we either do or<br>
> > relax specific constraints on some attributes. For example: if an<br>
> > AuthorizedDevice has its 'role' set to ACCESSPOINT, we require certain<br>
> > attributes must not be blank. While an AuthorizedDevice has its 'role' set<br>
> > to REMOTE, we relax certain constraints.<br>
> ><br>
> > I've tried to use grouping feature of Bean Validation but it doesn't seem<br>
> > to help in achieving the my goal. I agree we can always write custom<br>
> > constraints but that means I can't reuse the built-in validation<br>
> > constraints from the framework (not even in the case of writing a<br>
> > constraint composition). And certainly, I would not want to write a custom<br>
> > constraints for checking NotBlank. @ScriptAssert is no better than writing<br>
> > your own custom constraint.<br>
> ><br>
><br>
> Hi Thang,<br>
><br>
> There is a solution if you don't mind using a feature specific to the BV<br>
> reference implementation Hibernate Validator.<br>
><br>
> There you can dynamically re-define the default group sequence of an object<br>
> dependening on its state. So you could assign the constraints to two<br>
> groups, AccessPoint.class and Remote.class and return one or the other as<br>
> default group, depending on the value of the "role" attribute.<br>
> <a href="http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#d0e2886has" target="_blank">http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#d0e2886has</a><br>
> the details.<br>
><br>
> Maybe we should consider to add something like this to the spec.<br>
><br>
> --Gunnar<br>
><br>
</div></div><div class=""><div class="h5">> Thang<br>
> ><br>
> ><br>
> ><br>
> > On Thu, Jun 6, 2013 at 1:55 PM, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>wrote:<br>
> ><br>
> >> Hello,<br>
> >><br>
> >> You will have to dive into more concrete use cases. We did not add such a<br>
> >> feature so far for a few reasons:<br>
> >><br>
> >> - groups are offering a way to validate specific subset of constraints<br>
> >> 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<br>
> >> this. That's a bit less reusable but is more readable and could be done in<br>
> >> a more type safe way (than an EL)<br>
> >> - you can use constraints like Hibernate Validator's @ScriptAssert that<br>
> >> let's you write a free Groovy, EL, etc expression and be validated.<br>
> >><br>
> >> Emmanuel<br>
> >><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<br>
> >> written and assigned in static manner. This limits us to reuse the existing<br>
> >> constraints in value-driven manner. Could we add a new attribute<br>
> >> 'executeCondition' to the constrain definition? 'executeCondition' would<br>
> >> take an EL expression. A bean validation framework would need to evaluate<br>
> >> the expression set in this attribute. The corresponding constraint logic<br>
> >> only gets executed when the expression set for 'executeCondition' is<br>
> >> satisfied at runtime.<br>
> >> ><br>
> >> > Let me know your thoughts on this suggestion.<br>
> >> ><br>
> >> > Thanks,<br>
> >> > Thang<br>
> >> > _______________________________________________<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>
> >><br>
> ><br>
> ><br>
> > _______________________________________________<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>
> ><br>
</div></div></blockquote></div><br></div></div>