You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Daniel Miller <mi...@paonline.com> on 2004/07/08 04:35:28 UTC

[PATCH] ValidationResultsPublisher for easier integration

I have done some work on the validator. These are the problems that I have tried to address with the attached patches and interface:

1. The current FieldChecks in Struts is receiving too much information (i.e. ActionErrors and HttpServletRequest). Neither of these objects is needed for the actual validation--they are both used to let the framework know when a validation error occurs. There is some confusion here between the task of validating a field and "publishing" the fact that validation failures have occurred. I have come up with a way to separate these tasks--the attached org.apache.commons.validator.integration.ValidationResultPublisher interface provides a way for Validator users to easily handle validation results. The user will need implement this interface and pass an instance of it to the validator before invoking Validator.validate(). Dependencies such as HttpServletRequest and ActionErrors can be provided to the ValidationResultPublisher before it is passed to the Validator.

2. ValidatorResult does not provide all error information (e.g. the default error message associated with the ValidatorAction). Consequently, I am forced to pass the Field and ValidatorAction to my ValidationResultPublisher. Would it be acceptable/helpful to provide a Resources class like org.springframework.validation.commons.Resources that provides helper methods for extracting message keys and arguments from Field and ValidatorAction objects?

I have changed my original "publisher" idea from ErrorPublisher to ValidationResultPublisher. That way both success and failure can be observed by the user. One use case for this is auditing, which could be very useful to detect that all desired validations are occurring. I expect most people to simply detect and publish failures, ignoring successful validations.

At this point, FieldChecks (or something like it) no longer needs to worry about framework specific error handling--it just needs to relay the result of the validation (true or false; success or failure).

The included patches and interface should be all you need. Let me know if you have any ideas on how it could be refined or improved. I'd be especially grateful if anyone could think of a better name than "ValidationResultPublisher"--I can't.

Thanks,
Daniel Miller