Hi,
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):
- In order to validate credit card we have more than 3 constraints.
1. CardNumberValidator (Is it randomly entered or not?),
2. BlackListValidator (Is this blacklisted?)
3. BankValidator (Is Bank lets us to use it?)
- Our users can change their location up to a count (2 times in 3 months)
1. LegalCityValidator (Is there really such a city)
2. LocationChangerValidator (Is location changeble? Users can not
change their city very often.)
- Our email validations are extensive because of the nature our products.
1. LegalEmailChecking (Thanks to Hibernate)
2. BlackListEmailValidator
3. ForbiddenEmailValidator (Some of are users using forbidden
keywords such as domain names in their emails.)
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.
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.
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.
On 4 January 2012 15:32, <beanvalidation-dev-request(a)lists.jboss.org> wrote:
Hi,
Let me try and summarize what you want to be sure we are on the same page:
- you want sometimes to return one and only one failure per property
- you want some constraints to be validated before others (to be the one
displayed)
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).
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.
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.
Likewise, we could fake salience by providing a special group
```
package javax.validation.groups;
@GroupSequence({Level1.class, Level2.class, Level3.class, Level4.class,
Level5.class, Level6.class, Level7.class, Level8.class, Level9.class,
Level10.class})
interface Order {
interface Level1 {}
interface Level2 {}
interface Level3 {}
...
interface Level10 {}
}
```
Frankly I'd rather avoid it but that would work.