In the last month I considered and implemented a conditional validation for Hibernate Validator. What you they think about this idea?
The details, code and jar are in the JIRA:

http://opensource.atlassian.com/project ... owse/HV-38

As basic example, it would be possible to make this type of validation:


All the validations could have one applyIf that accepted a EL...

I am personally not a big fan of that,
for static conditional validation, I like this approach
http://opensource.atlassian.com/project ... owse/HV-22

however, your solution works just fine with custom validation annotations.

If EL has to be introduced, then your example could be rewritten like

@El(el="receiveNews==true && address != null")
public class MyBean {
}

HV-22 is good, and I had seen it before implementing this code (at the time I voted in it also).

But I think about HV-22 and HV-38 for different uses.

The HV-22 is for you to use same POJO in different forms (two/three contexts).
The HV-38 is for validating one form in different ways depending them information (data).

The HV-38 can be used in a great questionnaire, where a field can qualify the validation of several other fields. I do not see as to make this with context. It would be a great combination of contexts.

You understand what I am wanting to say?

HV-22 and HV-38 also can be used together!

Example:


I don`t know if Hibernate Validator would accept two @NotNull, but this is alone an example...

Yes I understand your point, but at that stage (esp the complex questionnaire), why not just writing a specific validator dedicated to the questionnaire. Sounds like just as simple and easier to read than those duplicated applyIf parameters

Questionnaire was alone an example to be easy to explain. But simple things also need conditional validation.

applyIf does not make to duplicate annotation. In this my example was duplicate because of context…

But in normal situations it would be thus:


How you would solve this problem using context?
Exists some solution?

As I said, since your case becomes more complex, why not write a bean level questionnaire validator?

Emmanuel, its idea of generic EL for the Bean does not function in this my example.
The validation rules (in this in case) need to be for field, not for bean.
The field 'type' (my example) is used in some different cases and 'applyifs'.

Then I have that to write one custom annotation for each type of bean? :/ :/

The problem is complicated because I do not have ready situation to use this. I am making a tool (plugin for the Eclipse), and would like to use it to generate annotations of Hibernate Validator. Then the validations will be chosen by the user, dynamically... also the rules of when they will be you validate (applyIf). The user will go to choose everything in the tool, and the tool goes to generate some things, also to place annotations in the Beans.

We have that to make something flexible so that the people use, of easy form.

I don't understand why it's not possible
Use an

There is no need for a specific annotation per bean type

Not work because this:

ONE:

This code could be rewritten to:



TWO:
Unable to replace the code below using the annotation @EL:

- The 'admin' user must have a more secure password, then has a @Length differently.
- Even adding the 'field' in @EL, it does not work for other examples that have two or more types of validations for the same field.

Why is 'field' useful for? I don't get it.

as for your second point, I'm not an EL expert but surely you can do something like

Hi Emmanuel, owwww...

Are you thinking of using the @EL in a different way than I imagined. Sorry.

I thought the @EL to enable or not a validation.
The 'field' is to identify which validation should be enable or not (in this case the scope is for field).

If so we would have the problem that I wrote in the last post.

----------

But even using that their concept of @EL, it does not solve the problem.
You wrote my example in @EL ignoring the other annotations of Hibernate Validator and rewriting everything in EL (password.length > 4).

You only wrote this because I wrote examples with NotNull or Length.

But imagine that in place of these annotations (NotNull, Length) I put a more complicated (@CreditCardNumber, @Amex, @Visa, @EAN, ..., ...)? You would rewrites it in EL?

The EL should not be used to rewrite the validation. It should be used only to enable or not an annotation that already exists in Hibernate Validator.

You understand?

I understand but in this case requirements can go on and on for ever
Why not apply @MyValidation1 on field1 only if @MyValidation2 on field2 passes and @MyValidation3 on field3 fails, etc etc.

At some point, the line between simplicity and expressiveness has to be drawn.

I don't understand...
@MyValidation1 = Custom Validation?

If it is we will return to some messages behind:


But if MyValidation1 is a validation of Hibernate Validator as dynamically apply it? How to apply or not according to the data?

I believe you are suggesting create customized annotations. But beyond work, an annotation of Hiberante Validator not have access to all the data from the bean to validate it internally.

interface Validator:


value => this field value

I don't really understand what you mean...

In my example, @MyValidation1 is either a built-in validator or a custom one.
What I am trying to say is that applyIf only solves a subset of the "dependency between validation rules" problem, and that's the reason why I am not really happy with it.
The generic solution, which I agree requires you to write a custom validator if you don't want the generic @El approach I gave, is to use a bean level validator. A bean level validator gets the bean instance passed to the isValid method (as opposed to a property level validator).

hi Emmanuel =)

Okay, @MyValidation1 was then a Bean Validator. In that case we would have to work to create the custom validators for each case.......

I will make some basic questions to try to better understand the solution you are proposing:

1) the Hibernate already has support for Bean Validators? (I don't remember to have seen it). I think that does not yet exist, right?

2) There dependence between the @MyValidation1 and the Bean? How @MyValidation1 would have access to attributes of the Bean? Using the dependency or reflection?

3) If I change the Bean, I have to also change the @MyValidation1?

4) @MyValidation1 would replace the Validators of the fields (NotNull, Length, Mastercard) or would enable / disable these validations?

5) If @MyValidation1 replace the validation of fields, I would have to rewrite the rules of the @Length, @Credicard, ... again in the @MyValidation1?

6) If @MyValidation1 not replace the validation of fields, as I do for him enabling a single validation (@NotNull) and not enable another validation (@Length)?


What problem the applyIf not solve?
You remember an example?
If there are any, we can try to improve the idea together.