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>
-
