You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@commons.apache.org by si...@apache.org on 2012/01/05 16:59:28 UTC
svn commit: r1227656 -
/commons/proper/validator/trunk/src/site/xdoc/tasks.xml
Author: simonetripodi
Date: Thu Jan 5 15:59:28 2012
New Revision: 1227656
URL: http://svn.apache.org/viewvc?rev=1227656&view=rev
Log:
spaces instead of tabs
removed trailing spaces, empty lines
Modified:
commons/proper/validator/trunk/src/site/xdoc/tasks.xml
Modified: commons/proper/validator/trunk/src/site/xdoc/tasks.xml
URL: http://svn.apache.org/viewvc/commons/proper/validator/trunk/src/site/xdoc/tasks.xml?rev=1227656&r1=1227655&r2=1227656&view=diff
==============================================================================
--- commons/proper/validator/trunk/src/site/xdoc/tasks.xml (original)
+++ commons/proper/validator/trunk/src/site/xdoc/tasks.xml Thu Jan 5 15:59:28 2012
@@ -29,7 +29,7 @@
The following is a list of items that need to be completed in
Validator. Contributions are welcome!
</p>
-
+
<ul>
<li>
Integrate the creation of javascript javadocs into the maven build. What will need to happen
@@ -37,57 +37,56 @@
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. See the 2.0 DTD <a href="validator_2_0_0_proposal.dtd">proposal</a> for specifics.
- </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>
+ <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. See the 2.0 DTD <a href="validator_2_0_0_proposal.dtd">proposal</a> for specifics.
+ </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>
</section>
</body>
</document>
-