More action with Struts 2
In a recent review of Struts 2 in Action, JW Blogger Oleg Mikheev notes that Struts 2 is "just a collection of extensions built upon WebWork, which is ultimately the right thing to learn before starting a Struts 2 project." While Struts 2 has some architectural flaws, Oleg calls WebWork well-designed, well-tested, and reliable. What are your experiences using Struts 2 and WebWork?

Also see "Hello World the WebWork way," a JavaWorld excerpt from WebWork in Action, by Patrick Lightbody and Jason Carreira.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Facilitate form processing with the Form Processing API

Use the new servlet-based API with JSPs and JavaBeans to process form data

By Ilirjan Ostrovica, JavaWorld.com, 04/27/01

When designing a solution and then writing code for it, I often face a dilemma: Should I build a quick solution to finish my work quickly, or should I spend more time early on to build a solution that I can reuse in a similar situation? The second temptation won when I started to build the Form Processing API.

Here are four possible steps (and substeps) involved in form processing implementation:

  1. Show the form with all its input elements
    • Generate the presentation code (HTML, XML code)
    • Write special requirements (syntax rules) beside each field, if any, like "this field is required"
    • Display default inputs, if any
  3. Validate the field values that come with the request parameters
    • Parse the request parameters
    • Check whether a value for the requested fields has arrived
    • Validate the text input values against respective syntax rules, if any
    • Validate the text input values against any database query, if any (e.g., you don't want duplicates)
    • Validate the text input values against any other component operating in the background, if any
  5. Reshow the form, in case the validation did not succeed
    • Write the appropriate error messages beside each field that didn't pass validation
    • Display the last user inputs for each field
    • Continue with Step 2 and loop as many times as needed until reaching Step 4
  7. Go on to the next page (if validation went well)


As you can imagine, or have experienced, implementing all these steps is quite a job. In this article, I'll show you how the Form Processing API can help you simplify this process.

Form processing domain analysis

Let's start with an object-oriented analysis of the form processing domain, at the class level. With a bit of OO brainstorming, I came up with the two main classes, FormElement and Form, and one interface, FieldController.

The FormElement class

The FormElement class represents the general concept of all form input elements: text fields, password fields, text areas, checkboxes, radio buttons, combo boxes, and list boxes. In spite of what it specifically represents, a FormElement object (also referred to herein as "field") has four main states (variables):

  • String name identifies the field (FormElement) to the server
  • String value represents a value that the field carries to the server
  • Boolean required represents a flag that shows whether or not an entry for the field is required
  • String errorMessage represents a message that will display a warning, an error message, or nothing beside the field's graphical representation


The first three variables require no further explanation, but the fourth one brings up the question, what would that text message be? With radio buttons, checkboxes, combo boxes, and list boxes, the errorMessage can:

  • State that the user should make at least one choice (in other words, that this field is required)
  • Warn the user that at least one choice should have been made (in the case that this field is required)
  • Show nothing in two cases: when the field is not required, and when the field is required but the user made a selection during the last submission


With text input fields like text fields, text areas, and password fields, the errorMessage can:

  • State that the user must fill this field (in other words, that this field is required)
  • Warn the user that he should have entered something (in the case that this field is required)
  • Warn the user that password entries must be the same (only in the case of password fields)
  • Warn the user that certain characters are prohibited (infinite variation of characters are possible here)
  • Warn the user that certain text entries are prohibited (infinite variation of text entries are possible here)


As you can see, the last two types of warning messages cannot be categorized (or hard-coded in the API), because their variation is infinite. In every infinite situation, FormElement needs some help to generate an errorMessage. Here is where interfaces come into play.

The FieldController interface

Since errorMessages for text input fields vary infinitely, the action for generating them varies infinitely too. But the scenario is always the same: a value is given, and a derived errorMessage is required. It all sounds like a method that takes value as an argument and returns errorMessage, while the implementation of that method is unknown.

FieldController is an interface that only defines one method, getErrorMessage(). This method takes a string value (being validated) as an argument and returns a string errorMessage.

A FormElement object, which represents a text input field, uses an object of type FieldController to implement validation criteria for its value. In this case, the FieldController object is said to be registered with the FormElement. For that purpose, the FormElement class has a method called addFieldController() that takes a FieldController object as an argument. Nothing can go wrong when a FormElement registers more than one FieldController.

The Form class

The Form class represents the concept of a whole set of FormElements. A Form object is responsible for processing a number of FormElement objects that belong to the form. Its process() method validates all field values, and returns "true" when all values are accepted, or "false" otherwise. See Resources for a look at the Form Processing API docs, and more information on Form and other classes.

To stay on track, I won't go deeper into this analysis. The simple UML class diagram below shows all the classes the API includes (in terms of methods, it only contains the most commonly used ones).

Figure 1. UML class diagram of the Form Processing API



All these classes belong to the iostrovica.form package. Check Resources for this package's class files, and the API specification.

A JSP and JavaBeans solution

In the J2EE programming model, JSP pages, supported by servlets, are responsible for delivering dynamic Web content to the client, and the complex business logic tasks should be encapsulated within JavaBeans components (or custom tags). The Form Processing API can be seen as an extension of the Servlet API. Its classes follow the JavaBean standard, giving you the comfort of enjoying all JSP and JavaBean features.

Resources