Stepping through the Struts 1.1 Validator
by Keld H. Hansen
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.
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.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
