FacilitatIMe form processing with the Form Processing API 2.0

Explore the new 2.0 features with JSP- and XSLT-based examples

By Ilirjan Ostrovica, JavaWorld.com, 10/05/01

(I suggest you read the first part of the original "Facilitate Form Processing with the Form Processing API" to fully understand this article; the example of that article no longer applies to the new version.)

With 2.0, that hierarchy is somewhat changed and looks like Figure 1.

At the center of this structure is the validate(HttpServletRequest request) method. This method validates all form fields based on criteria that FieldValidator and/or GroupValidator classes attach to each field. (Note that FieldValidator is a new name for 1.0's FieldController; GroupValidator is addressed below.) Thanks to the above class structure, a Form object can fully validate itself, so you can separate that validation from further form processing (in fact, I might have called this API Form Validation API).

In this article, I'll follow a how-to-use approach rather than show how the API works. Using FPAPI 2.0 in a Web application differs from the 1.0 version in three ways:

1. Designing forms
2. Presenting forms to the client
3. Validating fields in a group

Design forms and their fields in XML format

The final task in the form design operation is to create Form objects. In version 1.0, you had to create Form objects by writing Java code (extending class Form). With 2.0, you design forms by writing an XML form designer file called forms.xml; FPAPI then reads that file and creates all Form objects for you.

To create a Form object, the form designer file must define the following:

• Form name
• Path to the form's presentation file
• Path to the form's action
• Each field (FormElement) the form contains

To create a FormElement object, the form designer file defines the following:

• Name of class the field belongs to
• Field name
• In the case of RadioButtons, CheckBoxes, and MenuBoxes, all possible values those fields can take
• Field initial value, if any
• Whether the field is required or not
• Initial error message, if any
• Repeated error message, if any
• FieldValidator object(s), if any
• GroupValidator object, if any (2.0 only)

To create a FieldValidator or a GroupValidator object, the form designer file defines the following:

• Full class name
• Name of a reference variable to the object

A very simple forms.xml file might look like this:

<?xml version='1.0' encoding='utf-8'?>
<forms>
   <forms-field-validator name="postalCodeValidator "
      type="mypackage.PostalCodeValidator"/>
   <form name="myform"
      page="/jsp/myforms/myform.jsp"
      action="/actionPath">
      
      <field name="firstName"
         type="com.codepassion.form.TextBox">
      </field>
  
      <field name="lastName"
         type="com.codepassion.form.TextBox"
         required="true">
      </field>
      
      <field name="postalCode"
         type="com.codepassion.form.TextBox"
         required="true">
         <field-required-message>
            (please fill)
         </field-required-message>
         <field-validator>
            postalCodeValidator
         </field-validator>
      </field>
      <field name="age"
         type="com.codepassion.form.RadioButton">
         <field-value state="selected">
            20-30
         </field-value>
         <field-value>
            30-45
         </field-value>
         <field-value>
            45-60
         </field-value>
      </field>
   </form>
</forms>

You can easily see that each file element defines one item listed above. See the example application's forms.xml in the FPAPI 2.0 download for detailed instructions on using possible elements (tags) and their meaning. FPAPI 2.0 Javadocs also show how to express a class or a method through the form design file.