commons-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From simonetrip...@apache.org
Subject svn commit: r1227656 - /commons/proper/validator/trunk/src/site/xdoc/tasks.xml
Date Thu, 05 Jan 2012 15:59:28 GMT
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 &lt;form-validation&gt;, &lt;formset&gt;, &lt;form&gt;,
and &lt;field&gt; elements
-      		require a form-centric view of validations.  Changing these to &lt;bean-validation&gt;
or &lt;validator-config&gt;, 
-      		&lt;beans&gt;, &lt;bean&gt;, and &lt;property&gt; 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 &lt;form-validation&gt;, &lt;formset&gt;, &lt;form&gt;,
and &lt;field&gt; elements
+          require a form-centric view of validations.  Changing these to &lt;bean-validation&gt;
or &lt;validator-config&gt;, 
+          &lt;beans&gt;, &lt;bean&gt;, and &lt;property&gt; 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>
-



Mime
View raw message