Tutorials : Stepping through the Struts 1.1 Validator :

Stepping through the Struts 1.1 Validator

Introduction

Jakarta Struts is becoming increasingly popular as the de- facto MVC framework for servlet applications. Currently we’re all waiting for version 1.1 to be finally released. But, until this happens there’s no reason not to use the 1.1 Release Candidate, which is considered to be very stable, and at the API level it can be assumed to be identical to the final release.

One of the nice things in 1.1 is the inclusion of the Validator framework, which makes it much more effortless than before to implement simple form validation rules. In this article I'll show you how to use the new Validator. But first I’ll briefly go through how we did validation with Struts in the "old days", and then step up to how it’s done in 1.1, where the validation rules can be separated from the code by placing them in a configuration XML file.

To benefit from the article you need to have some experience with Struts, either version 1 or 1.1 RC. If you're new to Struts, I've written a couple of introductory articles, which quickly will bring you up to speed. They're listed in the resources section at the end of the article.

Validation before release 1.1

Before Struts 1.1 we had two choices of implementing forms validation: either in the ActionForm class or in the Action class. Both used the same technique to tell the Struts framework that validation errors were found: an ActionErrors object was returned holding a set of ActionError objects. Each of these described a specific validation error.

Using the ActionForm class, which is the bean that maps all the controls in the HTML form, you'd code something like this in the validate method:

ActionErrors errors = new ActionErrors();
if (some_test_fails) errors.add("label", new ActionError("errorkey"));
. . .
return errors;

label is used to connect the error message to the control that has an error, and errorkey is a key that points to the error message in the message resource file (often called ApplicationResources.properties). All simple validations (like syntax checks) should be placed in the ActionForm class.

The other approach is to validate in the Action class, and you'd typically do it here if the validation were coupled to the business logic. The setup is basically the same as above, but this time you must place the code in the perform method:

ActionErrors errors = new ActionErrors();
if (some_test_fails) errors.add("label", new ActionError("errorkey"));
. . .
if (!errors.empty()) {
  saveErrors(request, errors);
  // Return to same page 
  return (new ActionForward(mapping.getInput()));
}
. . .

This validation technique is still valid in Struts 1.1, and you may mix it with the new Validator, but it's much nicer to pull out the validation rules from the ActionForm and Action classes, and place them in a configuration file. It's more of a modular approach and it removes some of the bindings in your application. So if possible, use the new Validator, and if you have complex validations which don't fit in the new Validator scheme, then I'd recommend placing them in the Action class.

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.