<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">By the way the reason I do not like ordering numbers (the salience approach) is that it becomes quickly unmaintainable with meaningless numbers all over the place and it's hard to track why things are working a certain way. Groups have the advantage of being self-documented (at least by their name) and can be tracked with your IDE.<div><br></div><div>Oh and I don't have fond memories of my GWBasic code </div><div><br></div><div>10 foo</div><div>20 bar</div><div>25 boo</div><div>27 baa</div><div>28 Bii //hope I won't need more than 29 :(</div><div>30 baz</div><div>40 biz</div><div><div><br><div><div>On 4 janv. 2012, at 15:09, Cemo wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi,</div><div><br></div><div>Exactly. I would like to return only one failure per property in an ordered way. Let me to summaries a few more use cases (skipping empty,null constraints):</div><div><br></div><div><ul><li>
In order to validate credit card we have more than 3 constraints. </li></ul><ol><ol><li>CardNumberValidator (Is it randomly entered or not?), </li><li>BlackListValidator (Is this blacklisted?) </li><li>BankValidator (Is Bank lets us to use it?)</li>
</ol></ol></div><div><ul><li>Our users can change their location up to a count (2 times in 3 months)</li></ul><ol><ol><li>LegalCityValidator (Is there really such a city)</li><li>LocationChangerValidator (Is location changeble? Users can not change their city very often.)</li>
</ol></ol><div><ul><li>Our email validations are extensive because of the nature our products.</li></ul><div><ol><ol><li>LegalEmailChecking (Thanks to Hibernate)</li><li>BlackListEmailValidator</li><li>ForbiddenEmailValidator (Some of are users using forbidden keywords such as domain names in their emails.) </li>
</ol></ol></div></div></div><div><br></div><div>ReportAsSingleViolation is totally different than what we need by the way. It is also very useful but in terms of compositing new constraints. It can not let us to choose which constraint is violated and thus we can not display appropriated error message. The current spec is really addressing very well known issues such as partial validation, composite constraints but its usefulness for ordering is really questionable.</div>
<div><br></div><div>I am really suffering lack of this feature and I am sure that there are people like me. At Stackoverflow and community forum there are posts regarding it. At current situation we are reluctantly using as you proposed but as I mentioned before it is usability it is really annoying. </div>
<div><br></div><div>By the way maybe it is right time to say, these validations are used in a production system more than 150 million page view per month. Thanks experts for your efforts for a better community. </div><div>
<br></div><br><div class="gmail_quote">On 4 January 2012 15:32, <span dir="ltr"><<a href="mailto:beanvalidation-dev-request@lists.jboss.org">beanvalidation-dev-request@lists.jboss.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1dr">Hi,<br>
Let me try and summarize what you want to be sure we are on the same page:<br>
<br>
- you want sometimes to return one and only one failure per property<br>
- you want some constraints to be validated before others (to be the one displayed)<br>
<br>
Besides not empty which should be simply ignored by your unique email constraint, do you have other use cases? I would rather exclude null / empty from the list of use cases because it's a fairly pathological case and we plan on addressing that via a different mechanism (namely a way to mark a constraint validator as being called only on non null / non empty values).<br>
<br>
I've been trying to avoid numerical ordering (the fancy name is salience I believe) so far so I'd like to see concrete use cases that cannot be solved otherwise.<br>
<br>
Having a per property shortcut and a global shortcut would be a nice a easy feature to add. We left it out of 1.0 but it almost made it through.<br>
<br>
Likewise, we could fake salience by providing a special group<br>
<br>
```<br>
package javax.validation.groups;<br>
<br>
@GroupSequence({Level1.class, Level2.class, Level3.class, Level4.class, Level5.class, Level6.class, Level7.class, Level8.class, Level9.class, Level10.class})<br>
interface Order {<br>
interface Level1 {}<br>
interface Level2 {}<br>
interface Level3 {}<br>
...<br>
interface Level10 {}<br>
}<br>
```<br>
<br>
Frankly I'd rather avoid it but that would work.</div></blockquote></div><br>
_______________________________________________<br>beanvalidation-dev mailing list<br><a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev<br></blockquote></div><br></div></div></body></html>