11.3 Using an ActionForm with the Validator

You can't use the standard Struts ActionForm class with the Validator. Instead, you need to use a subclass of the ActionForm class that is specifically designed to work with the Validator framework. There are two root subclasses to select from, depending on whether you are planning to use dynamic ActionForms. Figure 11-1 shows the ActionForm and its descendants, to help you visualize the hierarchy.

Figure 11-1. The ActionForm class hierarchy

If you are using dynamic ActionForms, you should use the DynaValidatorForm branch of the hierarchy. If you are using standard ActionForms, you can use the ValidatorForm or one of its descendants instead.

Whether you use dynamic or regular ActionForms, the manner in which you configure the Validator is the same. Just be sure that whichever ActionForm subclass you choose, you configure the form-bean section of the Struts configuration file using the fully qualified class name. See "The form-beans element" in Chapter 4 for more details.

Dynamic or standard is only the first decision that you have to make when choosing the proper ActionForm subclass. Notice that in both the dynamic and standard branch of the ActionForm hierarchy in Figure 11-1, there are two versions of ValidatorForm. The parent class is called ValidatorForm, or DynaValidatorForm for the dynamic branch.

Each of these has a subclass that contains the name Action in its title. The subclass of the ValidatorForm is called ValidatorActionForm, and the subclass of the DynaValidatorForm is called DynaValidatorActionForm. The purpose of the two different versions is to allow you to associate the validation with the form-bean definition or the action definition. The ValidatorActionForm and DynaValidatorActionForm classes pass the path attribute from the action element into the Validator, and the Validator uses the action's name to look up the validation rules. If you use the ValidatorForm or DynaValidatorForm, the name of the ActionForm is used to look up the set of validation rules to use. The only reason for using one or the other is to have more fine-grained control over which validation rules are executed.

For example, suppose that an ActionForm contains three different validation rules, but only two of them should get executed for a particular action. You could configure the rules to perform only the subset of validation rules when that action gets invoked. Otherwise, all of the rules would be invoked. In general, using ValidatorForm or DynaValidatorForm should be sufficient for your needs.

Let's look at a more complete example of using the Validator framework. As in previous chapters, we'll employ the Storefront application to help us understand the Validator better. In particular, we'll look at the HTML form used to capture the shipping information during checkout of the Storefront application. This is shown in Figure 11-2.

Figure 11-2. Capturing the shipping address information

For this example, we are going to use a dynamic form. Therefore, we'll use the DynaValidatorForm class to capture the shipping address details. Because the checkout process will span multiple pages and we want to capture this information across pages, we will need to configure the form bean to have session scope. We will also capture all of the checkout properties in a single ActionForm class. Instead of having a ShippingForm and a CreditCardForm, we will have a single form called CheckoutForm that captures all of the information.

In our Struts configuration file, we set up the checkoutForm as shown here:

<form-bean   name="checkoutForm"   type="org.apache.struts.validator.DynaValidatorForm">   <form-property name="firstName" type="java.lang.String"/>   <form-property name="lastName" type="java.lang.String"/>   <form-property name="address" type="java.lang.String"/>       <form-property name="city" type="java.lang.String"/>   <form-property name="state" type="java.lang.String"/>   <form-property name="postalCode" type="java.lang.String"/>   <form-property name="country" type="java.lang.String"/>   <form-property name="phone" type="java.lang.String"/>     </form-bean>

The type attribute specifies the exact ActionForm subclass.

In early beta releases of Struts 1.1, the form-bean section required that you set the dynamic attribute to true when using dynamic ActionForms. This is no longer necessary, as the framework will determine whether the class specified in the type attribute is a descendant of the DynaActionForm class.

The next step is to edit the application-specific validation logic, which is done in the validation.xml file. You must declare a validation rule for each property in the form that you need to validate. In some cases, you might need to specify multiple rules. In Figure 11-2, for example, the phone field is required, and it must fit a specific format. These are two separate rules that both must evaluate to true, or the validation for the form will fail. The entire validation.xml file is not shown because it's too large and most of it is redundant. The section shown in Example 11-2 will help you understand how things are connected.

Example 11-2. A sample validation.xml file for the checkout form
<formset>   <constant>     <constant-name>phone</constant-name>     <constant-value>^\(?(\d{3})\)?[-| ]?(\d{3})[-| ]?(\d{4})$</constant-value>   </constant>                       <constant>     <constant-name>zip</constant-name>     <constant-value>^\d{5}(-\d{4})?$</constant-value>   </constant>                             <form name="checkoutForm">     <field        property="firstName"       depends="required,mask">       <arg0 key="label.firstName"/>                  <var>         <var-name>mask</var-name>         <var-value>^[a-zA-Z]*$</var-value>       </var>                         </field>     <field        property="postalCode"       depends="required,mask">       <arg0 key="registrationForm.zip"/>       <var>         <var-name>mask</var-name>         <var-value>${zip}</var-value>       </var>     </field>     <field        property="phone"       depends="required,mask">       <arg0 key="registrationForm.phone"/>       <var>         <var-name>mask</var-name>         <var-value>${phone}</var-value>       </var>     </field>            </form>              </formset>    </form-validation>

Now that we have everything configured for the Storefront, it's time to run the example. The nice thing about using a declarative approach versus a programmatic one is that once you have everything configured, you're ready to go. The absence of programming makes the declarative approach much simpler. This is especially true for the Validator framework. There's nothing to code, as long as the default validation rules satisfy your requirements.

When we submit the shipping address page with no information in the fields, the validation rules kick in. The result is shown in Figure 11-3.

Figure 11-3. The shipping address page using the Validator framework

Programming Jakarta Struts
Programming Jakarta Struts, 2nd Edition
ISBN: 0596006519
EAN: 2147483647
Year: 2003
Pages: 180

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net