Validation before bind

[edwing]

AFAIK there is no Framework supported way to do validation before binding the request parameters to the command object.
However this would be useful.

Consider following situation:
- command object with a java.util.Date property
- date format should be dd/mm/yyyy

I have configured a CustomDateEditor to parse such a submitted string into the Date property of my command object. If the submitted string is not correctly formatted, the exception thrown appears in my view (yuck).
I think there is a way to show this message in a cleaner way.

BUT, I would like to have some validator (like the commons-validator does now after the binding) that takes a look at the inputs ('is the date string in the format that the binder expects ?') before the binding occurs (similar like client-side validation, but now server-side).

Any ideas / comments ?

[davison]

I don't see what advantage this gives you - how does it help?

[edwing]

The advantage would be early filtering of wrong input data.

The, is the binder intended to do this ?

It seems more logical to me that e.g. a commons-validator 'required' check is executed on the input before binding, so there is almost no server processing to be done (no binding, no validation after binding and only then noticing this field was required, ...).

Ok, maybe it's just me thinking the wrong way, but then I'm glad someone puts me on the right track again ...

[davison]

yes, this is basically what the Spring validation framework and binding effectively gives you. Controllers generally don't start processing until this has happened. If you're round-tripping the request to the server anyway I really don't think you'd see any performance improvements at all.

Note that I think you can use source level meta data to generate JavaScript validation code that may help you, but I'm not personally familiar with it.

Regards,

[bpolka]

I agree with no advantage of early filtering. You should do it on the client side. As long as you let the request come to the server side let controller deal with it the way it needs to deal with it.

As for JavaScript check Matt Raible's integration with apache commons validation framework. It used to be in the sandbox, I am not sure of its whereabouts now.

[edwing]

Ok, I can follow the reasoning ... only thing is: 'company policy' is to avoid javascript at more or less all cost (not that I agree with it fully).

[ojolly]

We had this issue too and sort of solved it using a little hack.
You can have your property editor not throwing an exception but setting to null the returned value, and then on the onBind or eventually onBindAndValidate template method, you can compare the field value bind sooner and the request to see if any value were set. If command.field == null and request.getAttribute("field") != null, roughly, you can make a rejectValue on the Errors instance.
Hope it helps

Olivier

[Ben Alex]

For a cleaner way to error messages, see org.springframework.validation.DefaultMessageCodes Resolver JavaDocs.