[bv-dev] Ordered Validation (practically)

Cemo cemalettin.koc at gmail.com
Wed Jan 4 16:54:41 EST 2012


Hi,

Emmanuel, I can really see your points about ordering numbers (the salience
approach). I think that you are totally right. But in terms of usability
declaring again and again interfaces are killing usability. At your example
there is a still need for declaring them. And also at the order of the
constraints are can not be reached by reflection.

At this point I believe that defining order explicitly is the best. Maybe
like GroupSequence we can use ConstraintSequence whose target type "Field,
Method, Type" as opposite to GroupSequence whose target type "Type".
GroupSequence implies group related operations as expected, whereas
ConstraintSequence implies ConstraintSequence. For me really it makes sense.

For my use case I just want to not declaring again and again interfaces.
For M class and N field I have to declare (M) x (N) x (Annotation Count)
Interface. And without declaring interface I would like to have short
circuit feature.

Thanks





But there is another point too. Groups are used also for partial
validation. And groups are really implies this partial validation with its
name very good.

On 4 January 2012 16:29, <beanvalidation-dev-request at lists.jboss.org> wrote:

> Message: 3
> Date: Wed, 4 Jan 2012 15:25:10 +0100
> From: Emmanuel Bernard <emmanuel at hibernate.org>
> Subject: Re: [bv-dev] Ordered Validation (practically)
> To: beanvalidation-dev  List <beanvalidation-dev at lists.jboss.org>
> Message-ID: <9B5F338F-1682-438B-8270-A2A0E9DADE81 at hibernate.org>
> Content-Type: text/plain; charset=us-ascii
>
> I have what I think is a nice solution for BVAL-248 and for the uses case
> Cemo has
>
> The issue in this case is that you want the logic of group sequence but
> only per target (property, class, annotation).
>
> We can dot he following for that reusing HV-462's example
>
> ```
> interface Cheap {}
> interface Expensive {}
>
> @GroupSequence(value={Cheap.class,Expensive.class}, ordering=PER_TARGET)
> public class DomainObject {
>
>        @Size(max=50, groups=Cheap.class) // constraint 1a
>        @Pattern(regexp="[a-z]*", groups=Expensive.class)  // constraint 1b
>        private String name;
>
>        @Size(max=20, groups=Cheap.class) // constraint 2a
>        @URL(groups=Expensive.class) // constraint 2b
>        private String email;
>
>        @Size(max=100, groups=Cheap.class) // constraint 3a
>        @Pattern(regexp="[0-9]*", groups=Expensive.class) // constraint 3b
>        private String password;
> }
> ```
>
> The default @GroupSequence.ordering would be GLOBAL which is the current
> behavior.
>
> This solution is not technically as orthogonal than a true salience model
> but would that work for the use cases you have in mind?
>
> We can apply the same kind of solution on @ReportAsSingleViolation
>
> What do you think?
>
> Emmanuel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120104/f7f77e56/attachment.html 


More information about the beanvalidation-dev mailing list