| <?xml version="1.0"?> |
| <!-- |
| Copyright 2003-2004 The Apache Software Foundation |
| |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <document> |
| <properties> |
| <title>TODO</title> |
| </properties> |
| |
| <body> |
| <section name="TODO list"> |
| <p> |
| The following is a list of items that need to be completed in |
| Validator. Contributions are welcome! |
| </p> |
| |
| <subsection name="High priority"> |
| <ul> |
| <li> |
| Remove functionality deprecated in 1.1.0 release in 1.2.0 release. |
| </li> |
| </ul> |
| </subsection> |
| |
| <subsection name="Medium priority"> |
| <ul> |
| <li> |
| Integrate the creation of javascript javadocs into the maven build. What will need to happen |
| is something similar to the exec task in the ant build.xml. Then to put a Maven template around |
| the javadoc it and the legacy 1.0.2 javadoc will need to be copied to a temporary directory then the |
| html2xdoc task will need to be run against that temporary directory. |
| </li> |
| <li> |
| 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. |
| </li> |
| <li> |
| 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. |
| </li> |
| <li> |
| Examine the need for all dependencies. Validator has many dependencies that are very lightly used |
| and could be removed. Two likely candidates for removal are commons-collections and ORO. The first |
| because Validator only uses one class in a very large jar and backward incompatible changes in recent |
| versions. The second because it can easily be replaced with the faster and standard Java 1.4 regex |
| engine. |
| </li> |
| <li> |
| Scenario one: |
| Replace the Jakarta ORO regex engine with the standard Java 1.4 engine. Preliminary tests show a |
| 50% speed improvement using the standard engine. This will remove the ORO dependency and |
| bring Validator in line with standard Java regular expressions. However, this requires a move |
| to Java 1.4 as the base required Java version. A good time for this move may be Validator 2.0 when |
| we also change the configuration file semantics. |
| </li> |
| <li> |
| Scenario two: |
| ORO provides a much richer interface to regular expressions, such that we don't have |
| to worry about bit twiddling, this includes a pluggable regex engine. Jeffrey E Friedl states |
| in Mastering Regular Expressions 2ed, says that in speaking to the ORO developers that they |
| will likely develop an adapter to the Java 1.4 regex, See page 378. So we get use of ORO and the speed of |
| Java 1.4 Regex engine. |
| </li> |
| <li> |
| 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. |
| </li> |
| </ul> |
| </subsection> |
| |
| <subsection name="Low priority"> |
| <ul> |
| </ul> |
| </subsection> |
| </section> |
| </body> |
| </document> |
| |