xdocs/tasks.xml - commons-validator - Git at Google

 <?xml version="1.0"?>
 <!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You 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>

       <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 &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>
	<?xml version="1.0"?>
	<!--
	Licensed to the Apache Software Foundation (ASF) under one or more
	contributor license agreements. See the NOTICE file distributed with
	this work for additional information regarding copyright ownership.
	The ASF licenses this file to You 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>

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