Home arrow Java arrow Page 4 - Validator


The Struts framework features a built-in database for performing data validations on incoming form data. Its simple interface means that developers can focus on writing validation code; additionally, you can plug your own custom routines into Validator. This article shows you how. It is taken from chapter six of the book The Complete Reference Struts, written by James Holmes (McGraw-Hill/Osborne, 2004; ISBN: 0072231319).

Author Info:
By: McGraw-Hill/Osborne
Rating: 4 stars4 stars4 stars4 stars4 stars / 29
September 22, 2005
  1. · Validator
  2. · Validator Overview
  3. · Included Validations
  4. · Creating Form Beans
  5. · Configuring validation.xml
  6. · Enabling Client-Side Validations
  7. · Adding a New Validation Rule
  8. · Internationalizing Validations
  9. · Create a validation.xml File

print this article

Validator - Creating Form Beans
(Page 4 of 9 )

In order to use Validator, your applicationís Form Beans have to subclass one of Validatorís ActionForm subclasses instead of ActionForm itself. Validatorís ActionForm subclasses provide an implementation for ActionFormís validate( ) method that hooks into the Validator framework. Instead of hard-coding validations into the validate( ) method, as you would normally do, you simply omit the method altogether because Validator provides the validation code for you.

Parallel to the core functionality provided by Struts, Validator gives you two paths to choose from when creating Form Beans. The first path you can choose is to create a concrete Form Bean object like the one shown here:

package com.jamesholmes.minihr;
import org.apache.struts.validator.ValidatorForm;
public class LogonForm extends ValidatorForm {
  private String username;
  private String password;
public String getUsername() {
    return username;
public void setUsername(String username) {
    this.username = username;
public String getPassword() {
    return password;
public void setPassword(String password) {
    this.password = password;

This class is similar to one that you would create if you were not using Validator; however, this class extends ValidatorForm instead of ActionForm. This class also does not provide an implementation for ActionFormís empty reset( ) and validate( ) methods, because ValidatorForm does.

You configure this Form Bean in the struts-config.xml file the same way you would a regular Form Bean, as shown here:

  <form-bean name="logonForm" 
             type="com.jamesholmes.minihr.LogonForm"/> </form-beans>

The logical name given to the Form Bean with the form-bean tagís name attribute is the name that you will use when defining validations in the validation.xml file, as shown here:

<!DOCTYPE form-validation PUBLIC
          "-//Apache Software Foundation//DTD Commons
           Validator Rules Configuration 1.0//EN" 
          "http://jakarta.apache.org/commons/ dtds/validator_1_0.dtd">
<form name="logonForm">
<field property="username" depends="required">
        <arg0 key="prompt.username"/>

Validator uses the value of the form tagís name attribute to match validation definitions to the name of the Form Bean to which they are applied.

The second path you can choose when creating your Form Bean is to define a Dynamic Form Bean in the struts-config.xml file, as shown here:

  <form-bean name="logonForm"           
    <form-property name="username" type="java.lang.String"/>
<form-property name="password" type="java.lang.String"/>

Dynamic Form Beans do not require you to create concrete Form Bean objects; instead, you define the properties that your Form Bean should have and their types, and Struts will dynamically create the Form Bean for you. Validator allows you to use this concept just as you would with core Struts. The only difference for Validator is that you specify that your Form Bean is of type org.apache.struts.validator.DynaValidatorForm instead of org.apache.struts.action.DynaActionForm.

Identical to the way concrete Form Beans work with Validator, the logical name given to Dynamic Form Beans is the name that you will use when defining validations in the validation.xml file. Validator uses the matching names to tie the validations to the Form Bean.

In addition to the two standard options for creating Form Beans, Validator provides an advanced feature for tying multiple validation definitions to one Form Bean definition. When using ValidatorForm- or DynaValidatorForm-based Form Beans, Validator uses the logical name for the Form Bean from the struts-config.xml file to map the Form Bean to validation definitions in the validation.xml file. This mechanism is ideal for most cases; however, there are scenarios where Form Beans are shared among multiple actions. One action may use all the Form Beanís fields and another action may use only a subset of the fields. Because validation definitions are tied to the Form Bean, the action that uses only a subset of the fields has no way of bypassing validations for the unused fields. When the Form Bean is validated, it will generate error messages for the unused fields because Validator has no way of knowing not to validate the unused fields; it simply sees them as missing or invalid.

To solve this problem, Validator provides two additional ActionForm subclasses that allow you to tie validations to actions instead of Form Beans. That way you can specify which validations to apply to the Form Bean based on which action is using the Form Bean. For concrete Form Beans, you subclass org.apache.struts.validator .ValidatorActionForm, as shown here:

public class AddressForm extends ValidatorActionForm {

For Dynamic Form Beans, you specify a type of org.apache.struts.validator .DynaValidatorActionForm for your Form Bean definition in the struts-config.xml file:

<form-bean name="addressForm"    

Inside your validation.xml file, you map a set of validations to an action path instead of a Form Bean name, because if you have two actions defined, Create Address and Edit Address, which use the same Form Bean, as shown here, each has a unique action path:

  <action path="/createAddress"         
  <action path="/editAddress"

The following validation.xml file snippet shows two sets of validations that are intended for the same Form Bean, but are distinguished by different action paths:

<form name="/createAddress">
<field property="city" depends="required"
      <arg0 key="prompt.city"/>
<form name="/editAddress">
<field property="state" depends="required">
      <arg0 key="prompt.state"/>

Because your Form Bean subclasses either ValidatorActionForm or DynaValidatorActionForm, Validator knows to use an action path to find validations instead of the Form Beanís logical name.

blog comments powered by Disqus

- Java Too Insecure, Says Microsoft Researcher
- Google Beats Oracle in Java Ruling
- Deploying Multiple Java Applets as One
- Deploying Java Applets
- Understanding Deployment Frameworks
- Database Programming in Java Using JDBC
- Extension Interfaces and SAX
- Entities, Handlers and SAX
- Advanced SAX
- Conversions and Java Print Streams
- Formatters and Java Print Streams
- Java Print Streams
- Wildcards, Arrays, and Generics in Java
- Wildcards and Generic Methods in Java
- Finishing the Project: Java Web Development ...

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials