How to disable jsr 303 bean validation ?

[nothingman]

Hi,
I'm using spring-mvc and my domain beans are using jsr 303 bean validation annotation. (eg @NotNull, @Min, @Max etc).

My application should be able to turn off bean validation because if my user press the button "draft save" they should be able to save a "draft" version of the domain object bypassing all the validation.
Is it possibile to set a parameter that turn off temporary bean validation ?

Regards

Fabio

[smaetadena1228]

hai..
hope this link help you..
http://beanvalidation.org/1.0/spec/
if not, just helping...

[nothingman]

Thanx for you reply.
It seems to me that jsf can use the global parameter javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDAT OR to disable all validation and I'd like to use something similar with spring-mvc

Regards

Fabio

[Marten Deinum]

Your save-draft method should simply hook into another method on your controller which doesn't use @Valid(ate) ... Or do manual validation depending on the button pressed.

I assume you are only using the validation on the web side and not on the JPA side...

[nothingman]

Your save-draft method should simply hook into another method on your controller which doesn't use @Valid(ate) ... Or do manual validation depending on the button pressed.

Yes I'm currently doing as you suggested by it means to duplicate each save method in my controller...
It would be usefull to be able to simply turn off vaidation at "runtime"

[Marten Deinum]

Although everyone is preaching and teaching DRY, sometimes it is useful. To quote James Coplien 'We have been abstracting away the use-cases' ...

I think the code you end up with is a perfect real world representation of the different use-cases in your system. I could also envision a situation where the draft-save is just a simple save in the database, whereas the actual save triggers/sets of different actions.

There is a way but as mentioned you would have to do manual validation based on the draft or not-to-draft save.

[nothingman]

Although everyone is preaching and teaching DRY, sometimes it is useful. To quote James Coplien 'We have been abstracting away the use-cases' ...

I think the code you end up with is a perfect real world representation of the different use-cases in your system. I could also envision a situation where the draft-save is just a simple save in the database, whereas the actual save triggers/sets of different actions.

Correct... Draft save and normal save are different functional requirements... so it's not so bad manage them with two different methods