ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Using the Validator Framework with Struts
Pages: 1, 2, 3

Configuring the Validator for a Struts Application

One of the things that gives the Validator framework its flexibility is that all of the rules and details are declaratively configured in external files. Your application doesn't have to know anything about the specific validation rules. This characteristic allows the set of rules to be extended or modified without having to touch the code. This is very important when you have to customize each install of your application or when business requirements change, which they inescapably do.



When using the Validator framework with Struts 1.1, there are two configuration files used. One if called validator- rules.xml and the other is validation.xml. You can name these files anything that you want, or even combine the contents into a single XML file. However, it's better to leave them separated, because each one fulfills a slightly different purpose.

Note: If you just downloaded the Validator package from the Jakarta Commons site, these two files are not included. They are only present with a download of Struts, which includes the Validator.

The validator-rules.xml File

The validator-rules.xml file defines the Validator definitions available for a given application. The validator-rules.xml file acts as a template, defining all of the possible Validators that are available to an application.

Note: this XML file and the one we'll discuss next must be placed in a location where they can be found by the classloader. When using the Validator with a Web application, the correct location is under the WEB-INF directory.

The validator-rules.xml file is governed by validator- rules_1_1.dtd, which can be found and downloaded at jakarta.apache.org/struts/dtds/validator- rules_1_1.dtd. It would be too time-consuming to go into every detail about the XML definition file, so we'll just cover the essentials here.

The most important element within the validator-rules.xml file is contained with the <validator> element, as shown in Example 1.

Example 1. A simple validator-rules.xml File

<form-validation>
 <global>
  <validator 
     name="required"
     classname="org.apache.struts.util.StrutsValidator"
     method="validateRequired"
     methodparams="java.lang.Object,
                   org.apache.commons.validator.ValidatorAction,
                   org.apache.commons.validator.Field,
                   org.apache.struts.action.ActionErrors,
                   javax.servlet.http.HttpServletRequest" 
     msg="errors.required"/>
     
  <validator name="minlength"
     classname="org.apache.struts.util.StrutsValidator"
     method="validateMinLength"
     methodparams="java.lang.Object,
                   org.apache.commons.validator.ValidatorAction,
                   org.apache.commons.validator.Field,
                   org.apache.struts.action.ActionErrors,
                   javax.servlet.http.HttpServletRequest"
     depends="required"
     msg="errors.minlength"/>
 </global>
</form-validation>

There is one <validator> element for each validator that an application uses. In Example 1, there are two validators shown; one is the required validator and the other is the minlength validator. There are many attributes supported by the <validator> element. These attributes are necessary so that the framework knows the correct class and method to invoke on the Validator. For example, in the required validator element in Example 1, the method validateRequired() will be called in the org.apache.struts.util.StrutsValidator class. Validators can also depend on one another. This is shown in Example 1 with the minlength Validator. It includes a depends attribute, which indicates that it depends on the required validator. The msg attribute allows you to specify a key from a resource bundle that the framework will use to generate the correct error message. A resource bundle is used to help localize the error messages.

The <validator> element also supports a <javascript> child element that allows you to specify a JavaScript function that can be executed on the client side. In this way, both server-side and client-side validation can be specified in a single location, making maintenance easier.

The validation.xml File

The second configuration file for the Validator is normally named validation.xml, although again you are free to name it whatever you like or just put the contents into the validator-rules.xml file.

The validation.xml file is where you couple the individual Validators defined in the validator-rules.xml to components within your application. Since we are talking about using the Validator with Struts, the coupling occurs between the Validators and Struts ActionForm classes. ActionForm classes are simple JavaBean-like components within the Struts framework that capture user input and help to transfer the input to components deeper within the application. ActionForms also provide a convenient spot to validate the user input before passing it to the business layer. Example 2 shows a simple validation.xml file.

Example 2. A simple validation.xml File

<form-validation>
 <formset>
  <form name="checkoutForm">
    <field 
      property="firstName"
      depends="required">
      <arg0 key="label.firstName"/>
    </field>
         
    <field    
      property="lastName"
      depends="required">
      <arg0 key="label.lastName"/>
    </field>
  </form>
 </formset>
</form-validation>

Example 2 shows a <form> element with the attribute name equal to checkoutForm. The checkoutForm is an ActionForm that has been defined in the Struts configuration file. Therefore, the XML in Example 2 is coupling that ActionForm and its firstName and lastName properties (remember that ActionForms are simple JavaBeans) to the required Validator. This can be seen in the <field> elements, respectively.

There are actually many other features that allow you to define constants and global values that can be used throughout the validation.xml file. This comes in handy when you need to reuse certain constants or values over and over. For a more detailed discussion of the elements and attributes of the validation.xml file, you can download the DTD: jakarta.apache.org/struts/dtds/validation_1_1.dtd.

The Resource Bundle

The resource bundle is used to help localize messages and other textual information when dealing with users from various locales. It's also beneficial because it reduces the amount of redundant text hard-coded within an application. So instead of using the text label "Name:" directly within one or more JSPs, for example, you can put this text string within a resource bundle and pull the value from the bundle using a logical key. This way, if you needed to change the text label to "First Name:" you would only need to change it in one place.

For the Validator, the error messages that are created when validation rules fail come from the resource bundle. The Validator provides several default messages that can be placed in the Struts application resource bundle along with the normal application message resources. They look like:

#Normal resource bundle messages
label.firstName=First Name
label.lastName=Last Name

#Error messages used by the Validator
errors.required={0} is required.
errors.minlength={0} can not be less than {1} characters.
errors.maxlength={0} can not be greater than {1} characters.
errors.invalid={0} is invalid.
...

When a validation rule fails, an error message is created for that specific validation rule. The framework will also automatically insert parameters for the message. For example, if we were using the validation rules from Example 1 and 2 on the checkoutForm and the firstName property was null, we would see an error message like:

First Name is required.

You can also modify the messages within the bundle and/or configuration files to display any message you want.

Pages: 1, 2, 3

Next Pagearrow