Java Doc for AbstractValidatorAction.java in  » Content-Management-System » apache-lenya-2.0 » org » apache » cocoon » acting » Java Source Code / Java DocumentationJava Source Code and Java Documentation

Variant 1

 <map:act type="validator">
 <parameter name="descriptor" value="context://descriptor.xml">
 <parameter name="validate" value="username,password">
 </map:act>
 

The list of parameters to be validated is specified as a comma separated list of their names. descriptor.xml can therefore be used among many various actions. If the list contains only of *, all parameters in the file will be validated.

Variant 2

 <map:act type="validator">
 <parameter name="descriptor" value="context://descriptor.xml">
 <parameter name="constraint-set" value="is-logged-in">
 </map:act>
 

The parameter "constraint-set" tells to take a given "constraint-set" from description file and test all parameters against given criteria. This variant is more powerful, more aspect oriented and more flexibile than the previous one, because it allows comparsion constructs, etc. See AbstractValidatorAction documentation.

For even more powerful validation, constraints can be grouped and used independently of the parameter name. If a validate element has a rule attribute, it uses the parameter with that name as a rule template and validates the parameter from the name attribute with that rule.

This action returns null when validation fails, otherwise it provides all validated parameters to the sitemap via {name} expression.

In addition a request attribute org.apache.cocoon.acting.FormValidatorAction.results contains the validation results in both cases and make it available to XSPs. The special parameter "*" contains either the validation result "OK", if all parameters were validated successfully, or "ERROR" otherwise. Mind you that redirections create new request objects and thus the result is not available for the target page.

 <root>
 <parameter name="username" type="string" nullable="no"/>
 <parameter name="role" type="string" nullable="no"/>
 <parameter name="oldpassword" type="string" nullable="no"/>
 <parameter name="newpassword" type="string" nullable="no"/>
 <parameter name="renewpassword" type="string" nullable="no"/>
 <parameter name="id" type="long" nullable="no"/>
 <parameter name="sallary" type="double" nullable="no"/>
 <parameter name="theme" type="string" nullable="yes" default="dflt"/>
 <constraint-set name="is-logged-in">
 <validate name="username"/>
 <validate name="role"/>
 </constraint-set>
 <constraint-set name="is-in-admin-role">
 <validate name="username"/>
 <validate name="role" equals-to="admin"/>
 </constraint-set>
 <constraint-set name="new-passwords-match">
 <validate name="oldpassword"/>
 <validate name="newpassword"/>
 <validate name="renewpassword"
 equals-to-param="newpass"/>
 </constraint-set>
 <constraint-set name="all">
 <include name="is-logged-in"/>
 <include name="is-in-admin-role"/>
 <include name="new-passwords-match"/>
 </constraint-set>
 </root>
 

The types recognized by validator and their attributes

Default value takes place only when specified parameter is nullable and really is null or empty. Long numbers may be specified in decimal, hex or octal values as accepted by java.Lang.decode (String s).

Constraints

Constraints can be defined globally for a parameter and can be overridden by redefinition in a constraint-set. Thus if e.g. a database field can take at maximum 200 character, this property can be set globally.

Values in parameter arrays are validated individually and the worst error is reported back.

The attributes recognized in "constraint-set"