Re: [bv-dev] Ordered Validation (practically)

I have not seen your proposal till now. https://hibernate.onjira.com/browse/BVAL-220?focusedCommentId=42681&p... This looks quite elegant and only require BVAL-259 to be solved. Peter's proposal makes it work for any type and any definition of "null". The only drawback is that's it's more subtle / cryptic than an explicit param or annotation. On 4 janv. 2012, at 16:46, Peter Davis wrote: > 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&gt; 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 > _______________________________________________ > 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