@NotEmpty()

@IsValidBinCodeNumber()

@IsCardBannedNumber()

@IsValidCardNumber()

@ConstraintSequence(value={NotEmpty.class, IsValidBinCodeNumber .class,IsCardBannedNumber.class, IsValidCardNumber.class}, shortCirtcuit=true)

private String creditCard;

This approach is elegant for me. By the way Have you ever considered partial validation by ordered validation? Current solution based on Interfaces are simply killing :)

Thanks

On 5 January 2012 12:59, Hardy Ferentschik <hardy@hibernate.org> wrote:

We are talking about two things here, right?

1. That the validation of composed constraints should stop immediately if @ReportAsSingleViolation is specified and the first failing constraints has occurred. That's BVAL-259
BVAL-220 is an extension of BVAL-259 which makes the behavior configurable via something like this @ReportAsSingleViolation(shortCircuit=true)
The spec currently keeps the behavior open by saying (page 11, 2.3 Constraint composition):
"If a composing constraint fails and if the composed constraint is marked as @ReportAsSingleViolation, the Bean Validation provider is free to not process the other composing
constraints for this composed constraint."

2. The ability to define an order in which constraints are getting applied (either on a single property or also in connection of a composed constraint). That's BVAL-248 (and HV-462).
Here we have so far the idea of an additional order parameter added to constraints, e.g. @Size(max=100, validationOrder="1") and Emmanuel's @GroupSequence(value={Cheap.class,Expensive.class}, ordering=PER_TARGET)

Regarding 1, I think implementing BVAL-259 and BVAL-220 makes sense. In this context we should, however, also discuss boolean composition (BVAL-260) of constraints.

Regarding 2, Emmanuel's idea seems more in the spirit of the current spec design, but I disagree that the interface approach is easier to manage the order property. I think that Cemo has a point
that juggling all these interfaces around is at no means easier. Given that we talk about a order specific for a property I think it is easiest to understand if you you can specify and see it right there on
the constraint specified at the property.

--Hardy

On Jan 5, 2012, at 11:28 AM, Emmanuel Bernard wrote:

> I have not seen your proposal till now.
>
> https://hibernate.onjira.com/browse/BVAL-220?focusedCommentId=42681&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-42681
>
> 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@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@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev