TODO list
The following is a list of items that need to be completed in
Validator. Contributions are welcome!
-
Change the validation.xml file semantics to match a more general "bean" validation usage.
Currently, the <form-validation>, <formset>, <form>, and <field> elements
require a form-centric view of validations. Changing these to <bean-validation> or <validator-config>,
<beans>, <bean>, and <property> respectively would allow Validator to be used more easily in
non-form based environments. See the 2.0 DTD proposal for specifics.
-
The above changes to validation.xml could only apply to Validator's native configuration format. We
could add a ValidatorResources constructor that accepts a digester-rules file to allow parsing any
XML format into Validator configuration objects. This would allow higher level frameworks like Struts
to use configuration semantics specific to their domain.
-
ValidatorException is only thrown to indicate configuration and programmer errors
yet is a checked exception. ValidatorException should be converted to a RuntimeException to match its
real purpose. Furthermore, the exception handling for pluggable validations (ValidatorActions)
is not well defined or documented. RuntimeExceptions thrown from ValidatorActions should be propogated
out of the Validator framework as is because they indicate programmer error. Checked exceptions thrown
from a ValidatorAction should stop validation and be propogated out of the framework for handling as these
indicate an unrecoverable system failure. Validation method implementation becomes easier because they
can throw SQLException, IOException, etc. instead of wrapping the exception or defining it as a rule failure.
This allows clients to reliably distinguish between a normal validation failure (invalid data) and exceptional
conditions.
|