commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Jakarta Commons Wiki] Updated: ValidatorWishList
Date Tue, 22 Jun 2004 03:24:13 GMT
   Date: 2004-06-21T20:24:13
   Editor: <>
   Wiki: Jakarta Commons Wiki
   Page: ValidatorWishList

   no comment

Change Log:

@@ -23,5 +23,33 @@
+== Validator Integration with Frameworks Other Than Struts ==
+I have written an adapter of the Commons-Validator for the [
Spring] project. While considering if the adapter could be released (moved out of the sandbox),
it was determined that there were two classes that were outside the scope of Spring that should
be maintained as part of the Commons-Validator project. The following suggestions provide
an outline of how this can be done without breaking backward compatibility. Both of the classes
mentioned below can be found in the Spring sandbox as well as the Struts source code (customized
respectively for each framework).
+'''Commons-Validator should maintain the FieldChecks class.''' Currently FieldChecks is a
class that Spring (as well as Struts and any other framework that wants to support Commons-Validator
out of the box) must provide to connect Validator to the specific framework's error handling
mechanism. It would be nice if the Validator project would abstract the framework-specific
part of the FieldChecks class out to a simple interface something like this:
+public interface ValidationErrorPublisher {
+    /**
+     * Framework-specific error message publisher.
+     * 
+     * @param field The field to be validated.
+     * @param va The ValidatorAction for which the error occurred.
+     * @param parameters Parameters passed to the Validator via setParameter().
+     */
+    void publishError(Field field, ValidatorAction va, Map parameters);
+Then any framework could simply maintain an implementation of this interface instead of the
entire FieldChecks class with all of its validation specific code. As a side benefit, a standard
version of validation-rules.xml could be provided by Validator because frameworks would no
longer have to tell Validator how to call each validation rule.
+'''JavascriptValidatorTag should be maintained with Commons-Validator.''' Validator should
at least provide a version of this class with abstract dependency retrieval methods (getValidatorResources
and getMessage) so that a framework could simply extend the abstract class to provide this
tag. Ideally, Validator would have its own tag library, but I can't think of how this would
be implemented easily.
+[mailto:millerd_AT_paonline_DOT_com Daniel Miller]
 Up to [:Validator]

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message