[hibernate-issues] [Hibernate-JIRA] Commented: (HV-462) Allow ordered validator's annotations

Hardy Ferentschik (JIRA) noreply at atlassian.com
Tue Sep 27 11:09:35 EDT 2011


    [ http://opensource.atlassian.com/projects/hibernate/browse/HV-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43731#comment-43731 ] 

Hardy Ferentschik commented on HV-462:
--------------------------------------

I see where you are coming from. I still it is possible with the current approach, but cumbersome:

{code}
public class DomainObject {
	@Size(max=50, groups = NameStep1.class)
	@Pattern(regexp="[a-z]*", groups = NameStep2.class)
	private String name;
	
	@Size(max=20, groups = EmailStep1.class)
	@URL(groups = EmailStep2.class)
	private String email;

}

@GroupSequence({ NameStep1.class, NameStep2.class })
public interface NameSequence{
}

public interface NameStep1 {
}

public interface NameStep2 {
}

@GroupSequence({ EmailStep1.class, EmailStep2.class })
public interface EmailSequence{
}

public interface EmailStep1 {
}

public interface EmailStep2 {
}
{code}
At validation time you would then validate the groups _NameSequence_ and _EmailSequence_.
Obviously {quote}validation should occur in ordered steps given by order of annotations for given property{quote} is not possible, because there is no way to introspect the order of annotations for a given property. Leaves the _order_ which is really a change the Bean Validation spec and should be discussed there. I wonder how such an attribute would then tie in with the current group and group sequence mechanism?

> Allow ordered validator's annotations
> -------------------------------------
>
>                 Key: HV-462
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-462
>             Project: Hibernate Validator
>          Issue Type: New Feature
>    Affects Versions: 4.1.0.Final
>            Reporter: Pavla Nováková
>             Fix For: 4.x
>
>
> 1) Consider domain object with simple constraints (just to demonstrate required feature, my real example uses custom cost-expensive validation of pictures):
> {code}
> public class DomainObject {
> 	@Size(max=50) // constraint 1a
> 	@Pattern(regexp="[a-z]*") // constraint 1b
> 	private String name;
> 	
> 	@Size(max=20) // constraint 2a
> 	@URL // constraint 2b
> 	private String email;
> 	
> 	@Size(max=100) // constraint 3a
> 	@Pattern(regexp="[0-9]*") // constraint 3b
> 	private String password;
> 	
> {code}
> 2) Consider validation requirements:
> * all properties should be validated together (like one virtual group)
> * FOR EACH PROPERTY validation should occur in ordered steps given by order of annotations for given property (if first validation step fails, SKIP following validation process on given property and add validation message specific to failed / last validated constraint for the property)
> 3) Why it is useful:
> * simple cost-effective validation followed by cost-expensive validation (not executed if simple constraint fails)
> * we get just the "main and specific validation error" (otherwise we have to iterate over all errors "to find the cause" or we display two or more errors for one property which is not user-friendly according my opinion)
> 3) What is unusable:
> * groups and group sequences (it is not possible to create proper combination of groups and sequences for more than one property with two or more constraints)
> * composed constraints (@ReportAsSingleViolation included)
> ** we cannot use @ReportAsSingleViolation since we want specific message for each failed constraint
> ** and main problem is: if we use composed constraints all constraints are evaluated for given property 
> 4) Proposed solution:
> * add optional order attribute to validator annotations and stop validation on first failure if order is specified
> * possibly this can be configured on global validator level with property "skipOnFirstFailure" together with some given convention for annotation order
> Please let me know if need better explanation or working examples.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



More information about the hibernate-issues mailing list