email article printer friendly get the code

Form Validation and Action Mapping
Employ XDoclet to add server-side form validation and action mapping
by Erik Hatcher

Let's make the first name field required to add server-side validation to our form. Struts developers have been leveraging the Jakarta Commons Validator framework, and Struts 1.1 comes with built-in support for it. I have seen many projects soaked in hand-coding validation constraints in the validation.xml file, and I could not stand to see that level of duplication occurring further, so I created the <strutsvalidationxml> subtask in XDoclet to DRY things off a bit. (As mentioned in the previous installment, DRY refers to "Don't Repeat Yourself!") To make a field required, it only requires tagging the setter like this:

/**
  * @struts.validator type=
  * "required"
  */
public void setFirstName(
  String fn) {
  this.firstName = fn;
}

Doing justice to the savings that this one simple tag accomplishes is beyond the scope of this discussion. The validation.xml file is verbose and requires a lot of duplicate information that is already present in our form bean code: form name, property names, and now validation types.

Action mappings in struts-config.xml can also be generated from Action subclasses tagged appropriately. You can see the tags necessary for generating a typical Struts action mapping (see Listing 2). When adopting XDoclet, though, it is not necessary to use it for the entire struts-config.xml generation. In production, I prefer to hand code the action mappings, despite XDoclet's generation capabilities. Merging static content into XDoclet-generated artifacts is a provided feature, using merge points that are places in the templates that pull in an external file. The files reside in the mergedir (see Listing 1 in "Exploit XDoclet's Struts Capabilities"), and must adhere to naming conventions documented within XDoclet, and also within the generated artifacts (look for XML comments that indicate them). For hand-coded Struts action mappings, the <strutsconfigxml> subtask looks for a struts-actions.xml file in the mergedir. The mergedir attribute can be specified globally for the <webdoclet> task and can be overridden on a subtask basis if desired.

We could happily leave things alone now and be satisfied that we have dramatically streamlined our development process. The two deployment descriptors in the Struts world are now tamed and under tight control. There is still room for improvement even here. Let's walk through the situation where a new form is added to the system. In our nice Struts and XDoclet environment, adding a form involves creating a new form bean, tagging it with its name mapping and any validations required, writing an action to process the form, and a JSP page to display the form. Ideally we also want our field labels and page titles localized rather than hard-coded into the JSP pages. Struts provides a resource abstraction layer and a helper tag library to display them in JSP pages.