9:46 a.m.
Can the proposal for special null/empty handling be generalized? I have
two extra use cases,
- Concept of "empty" for objects, for example my enterprise often uses a
"money" object (value+currency)
- Need to define "prerequisite" validations in general, for example check
@NotNull+@Size before a DB query to avoid a query exception
Regards,
Peter Davis
On Jan 4, 2012, at 5:29, Emmanuel Bernard <emmanuel(a)hibernate.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.
On 3 janv. 2012, at 21:33, Cemo wrote:
Hi experts,
After reading your comments and mail list I realized that it will be better
share our opinions here about our problems.
First, I would like to thanks all of you to provide such an elegant library
and spec. After latest improvements at spring side, I am sure that bean
validation will be defacto validation framework among java community.
The only problem We are facing is that ordered validations.
In a common sense validation such this can be feasible:
public class AccountBean {
@CheapValidation(groups=Name1.class)
@ExpensiveValidation(groups=Name2.class)
@VeryExpensiveValidation(groups=Name3.class)
String name;
@CheapValidation(groups=Surname1.class)
@ExpensiveValidation(groups=Surname2.class)
@VeryExpensiveValidation(groups=Surname3.class)
String surname;
public interface Name1 {}
public interface Name2 {}
public interface Name3 {}
@GroupSequence({Name1.class, Name2.class, Name3.class})
public interface Name {}
public interface Surname1 {}
public interface Surname2 {}
public interface Surname3 {}
@GroupSequence({Surname1.class, Surname2.class, Surname3.class})
public interface Surname {}
}
There is two common usage for this. The first usage: some validations are
expensive that should be runned if all validations pass. Another usage is
for each field there should be one violation. For email, if it is empty,
uniqueEmail constraint must not be checked. I hope that how much necessary
it is for us you can imagine. Almost all fields has such restrictions.
Ordering and shortcutting are crucial for us.
But just to provide validation order and shortcut GroupSequence is
practically impossible to use at enterprice level. For each field again
and again we are declaring interfaces. It is not only intuitive but also
seems ugly. By the way what is came to my mind is for each constraint,
declaring a order like this:
public class AccountBean {
@CheapValidation(order=0,groups=Name1.class)
@ExpensiveValidation(order=1,groups=Name2.class)
@VeryExpensiveValidation(order=2,groups=Name3.class)
String name;
@CheapValidation(order=0,groups=Surname1.class)
@ExpensiveValidation(order=1,groups=Surname2.class)
@VeryExpensiveValidation(order=2,groups=Surname3.class)
String surname;
}
Default value for ordering might be same for all constraints.
Please help community. :)
Thanks & happy new year
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev