Recipe8.4.Validating Dependent Fields in Struts 1.2

Recipe 8.4. Validating Dependent Fields in Struts 1.2

Problem

You are using Struts 1.2 and you want to validate a field based on the value of another related field.

Solution

Use the validwhen validator. The field element in the following snippet from a validation document indicates that the zipCode is valid when the following occurs:

• The city and state properties are not null (regardless of the zipCode value).

• The zipCode is not null:

  <form name="AddressForm">   <field property="zipCode" depends="validwhen">       <arg key="prompt.zipCode"/>       <var>           <var-name>               test           </var-name>           <var-value>               (((city != null) and (state != null)) or (*this* != null))           </var-value>       </var>   </field> <form name="AddressForm">

  
  

Discussion

The validwhen validator, available with Struts 1.2, replaces requiredif for performing cross-field validations.

The validwhen validator, like requiredif, can't be used for client-side validation, only server-side validation.

As in Recipe 8.3, the Solution shows how you would set up the validation on a form where you were retrieving a user's address. If users specify a zip code, then they can omit the city and state; otherwise, if the city or state is not specified, the zip code is required.

With validwhen, you can code a single expression that takes the place of multiple XML elements needed for requiredif. The validwhen validator is more powerful than requiredif, though it can be trickier to get the logic correct. With requiredif, your validation makes the assertion "this field is required if...." The validwhen validator is different in that it asserts the statement "this field is valid when..." followed by a boolean expression. The criteria that make up the expression are open-ended.

When you create the test expression for validwhen, ensure that the expression has a way to evaluate to true; otherwise, the page will never pass validation.

In the Solution, the validation ensures that a zip code must have a value if the city or state is null. Likewise, if the city and state aren't null, then the zip code doesn't have to be specified; it can be null. The following expression from the Solution enforces this logic:

(((city != null) and (state != null)) or (*this* != null))

The *this* notation in the expression represents the value of the field being validated, the zip code. If the zip code isn't null the expression will be true regardless of the city and state values. If the city or state is null and the zip code is null, the expression evaluates to false; the zip code isn't valid. Finally, if the city and state have values, the zip code can be any value, including null.

The kinds of values allowed in a validwhen expression are the following:

• Single- or double-quoted string literals

• Integer literals in decimal, hex, or octal format

• The value null, which will match against null or an empty string

• Other fields in the form referenced by field name, such as customerAge

• Indexed fields in the form referenced by an explicit integer, such as childLastName[2]

• Indexed fields in the form referenced by an implicit integer, such as childLastName[], which will use the same index into the array as the index of the field being tested

• Properties of an indexed fields in the form referenced by an explicit or implicit integer, such as child[].lastName, which will use the same index into the array as the index of the field being tested

• The literal *this*, which contains the value of the field currently being tested

The Validator parses the test expression using the ANTLR parser.

The expression syntax is strict and unforgiving.

The entire expression must be enclosed in parentheses. Each logical statement, such as (foo == bar), contained in the expression must be enclosed in parentheses; using an editor that matches parentheses can help. Here are some practical guidelines for crafting validwhen expressions:

• Think completely through the logic of the test expression. Ensure the expression can evaluate to true under some set of circumstances.

• Be precise with the parentheses and whitespace in the expression.

• In testing, if the validation unexpectedly fails, check the container's log file or console output before you starting questioning your logic. You have made a typo in the validation.xml file or the validwhen expression can't be parsed for some reason.

See Also

If you are using Struts 1.1, validwhen is not available. You may be able to use the requiredif rule, discussed in Recipe 8.3.

The latest documentation on the built-in pluggable validators can be found in the Struts Validator Guide available at http://struts.apache.org/userGuide/dev_validator.html.