Conditional or event-based validation

bruno.braga · **Joined:** Fri Nov 03, 2006 3:21 pm **Posts:** 30

Why instead of doing this:

Code:

@NotNull
@Lengths({
@Length(validationConditions="user", min=4, max=20),
@Length(validationConditions="admin", min=8, max=20)
})
public String getPassword() {
return password;
}

@ValidationConditionOnUELs({
@ValidationConditionOnUEL(name="admin", uel="this.userType == 'admin'"),
@ValidationConditionOnUEL(name="user", uel="this.userType == 'user")
})
public String getUserType(){
return userType;
} 

You don't do this?

Code:

@ValidationConditionOnUELs({
@ValidationConditionOnUEL(name="admin", uel="this.userType == 'admin'"),
@ValidationConditionOnUEL(name="user", uel="this.userType == 'user")
})
public class User {

private String password; 
...

@NotNull
@Lengths({
@Length(validationConditions="user", min=4, max=20),
@Length(validationConditions="admin", min=8, max=20)
})
public String getPassword() {
return password;
}

public String getUserType(){
return userType;
} 
}

The rules of @ValidationConditionOnUEL can be used in any properties validation of this class.

FroMage · **Joined:** Tue Apr 01, 2008 11:10 am **Posts:** 69

Both are equivalent, I don't think it matters where you put the @ValidationContionOnUEL since it has access to the whole entity in any case.

bruno.braga · **Joined:** Fri Nov 03, 2006 3:21 pm **Posts:** 30

Hi FroMage,

Put the @ValidationConditionOnUEL in the class seems more organized if you use the group "user" or "admin" on several properties.

Their solution is similar to mine, but you use groups + EL.

I think the idea of using groups is good and will be important in many cases.

But for this simple example, it's more clean:

Code:

public class User {

private String password;
...

@NotNull
@Lengths({
@Length(uel="this.userType == 'user", min=4, max=20),
@Length(uel="this.userType == 'admin'", min=8, max=20)
})
public String getPassword() {
return password;
}

public String getUserType(){
return userType;
}
}

I don't need to create groups that will only be used once.
The less code better to write and understand. What do you think about it?

The two ideas could not work together? We need to create groups of @ValidationCondition to use only once?

FroMage · **Joined:** Tue Apr 01, 2008 11:10 am **Posts:** 69

It would be nice to have any validator annotation have all the possible conditional attributes, but since annotations are so limited (there is no inheritance for some reason), it would mean that every implementation of validator annotations would have to define X number of "standard" attributes (on top of "groups" and "message").

I'm just trying to limit the number of such "standard" attributes by moving the definition of validation conditions away from their references. Plus it improves reusability. At the cost of simple cases, you are right.

FroMage · **Joined:** Tue Apr 01, 2008 11:10 am **Posts:** 69

I've written a lengthy article at http://www.lunatech-research.com/archiv ... validation detailing the limits we've hit with Hibernate Validation and Seam, along with a more in-depth description of my conditional/event-based validation.

I hope it will be useful for JSR-303, not necessarily to get my proposal accepted, but at least to explain why we need a similar feature :)

gus · **Posted:** Mon May 12, 2008 1:42 pm

Stéphane, really great article.

I wonder if @ValidationConditionOnTrue and @ValidationConditionOnUEL could be simplified to a single annotation, with meaning derived from context of usage and parameters given?

I agree with you that this topic of conditional validations needs to be addressed in some fashion by the JSR. These are practical concerns we've clearly had to deal with in our non-standard validation mechanisms, so the standard should address then too.

I keep thinking that if some kind of agreement on a standard implementation cannot be reached, or even if one is, but it is not sufficient for some folks, that hooks into the validation process beyond simply adding a custom validator are needed.

One could do a lot with these capabilities:
1) Ability to programmatically drive which validations are executed, and in what order. (This is different from external events). JSR currently provides Groups as an OOTB implementation.
2) Access to all available state of the validation process (e.g. validations executed so far, and their results in their full glory). JSR doesn't provide this currently?
3) Ensure the metadata model of the JSR is complete and flexible (e.g. anywhere a 1-1 assumption is made, evaluate if 1-M is possible). JSR has some limitations here currently (e.g. InvalidConstraint is single bean/property centric).

In our custom framework, there are some automatic conditional evaluation rules we implement (e.g. no need to declare them) which define semantics between basic single field validations and complex cross field validations. For example, any complex cross field validation has an automatic pre-condition on each of it's input properties of 'if property X is not already marked in error by a basic field validation'. Essentially, if you can't get the most fundamental validations to work, don't bother with complex ones.

We also can mark multiple input properties in error as part of a single validation. For example, if the sum of A and B must be less than 100, both A and B are equally in error, and the user must decide which of the two to modify (or both) to correct the problem.

I cannot imagine how I'd get all this to work with the JSR currently.

My basic point here is that with the proper extension points, the JSR could provide a foundation upon which one can implement validation semantics outside the scope of JSR.

emmanuel · **Posted:** Mon Jun 02, 2008 7:25 pm

Thanks for the blog entry stephane.

genman · **Joined:** Wed Jul 25, 2007 6:33 pm **Posts:** 9

gus wrote:

I wonder if @ValidationConditionOnTrue and @ValidationConditionOnUEL could be simplified to a single annotation, with meaning derived from context of usage and parameters given?

The problem I have with the @ValidationBlahBlahBlah is the name is way too long to me. It's not very concise.

To me, "groups" and "condition" smell like the same thing. I would either have one or the other feature. Or try to combine the two by using terminology like "scope" or "context".

Here's my proposal:

Code:

public class {

@SetCondition("needEmail")
boolean needEmail() { return sms == null; }
@SetCondition("needSms")
boolean needSms() { return email == null; }

@NotNull(condition="needEmail")
String email;

@NotNull(condition="needSms")
String sms;

Sure it's not exactly pretty, but it gets the job done.