Using the ActionForm class has many advantages over performing the functionality yourself in the Action class or some set of helper utility classes. Because the behavior the ActionForm class provides is needed in nearly every web application and often many times in the same application, using the framework to perform the work can really reduce the development time and your frustration level. However, there are a few very important downsides to using ActionForms.
The biggest problem with using ActionForms is the sheer number of classes that it can add to a project. Even if you share ActionForm definitions across many pages, the additional classes make it more difficult to manage and maintain a project. This is why some developers create a single ActionForm and implement the properties for all of the HTML forms within it. The problem with this approach, of course, is that combining the fields into one class makes it a point of contention on a project that has more than just a few developers.
Another major liability is the requirement to define the properties in the ActionForm that need to be captured from the HTML form. If a property is added or removed from the HTML form, the ActionForm class may need to be modified and recompiled.
For these reasons, a new type of ActionForm, which is dynamic in nature and allows you to avoid having to create concrete ActionForm classes for your application, was added to the framework. The dynamic ActionForm is implemented by the base class org.apache.struts.action.DynaActionForm, which extends the ActionForm class. There are only three real differences between the ActionForms for any application:
The properties for a DynaActionForm are configured in the Struts configuration file and will be illustrated in the next section. The reset() method is called at exactly the same time during request processing as it is for a standard ActionForm. The one difference is that you have a little less control over what you do during the method invocation. However, you can subclass the DynaActionForm to override the reset or validate behavior.
The validation of the presentation data for a DynaActionForm is a little more complicated. We'll need to wait until we talk about the Struts Validator components before covering this topic.
7.5.1 Configuring Dynamic ActionForms
To use the DynaActionForm in your Struts application, first you need to add a form-bean element to the configuration file, just as with regular ActionForms.
When it comes to the configuration file, the difference between a regular ActionForm and a DynaActionForm is that you must include one or more form-property elements in order for the dynamic form to have properties. The DynaActionForm uses a java.util.Map internally to store the property key/ value pairs. The form-property elements are loaded into the Map and become the properties that get populated by the framework.
An example of configuring a DynaActionForm in the Struts configuration file is shown in Example 7-6.
Example 7-6. A DynaActionForm must be specified in the Struts configuration file
<form-beans> <form-bean name="loginForm" type="org.apache.struts.action.DynaActionForm"> <!-- Specify the dynamic properties of the form --> <form-property name="email" type="java.lang.String "/> <form-property name="password" type="java.lang.String "/> <!-- You can also set the initial value of a property --> <form-property initial="false" name="rememberMe" type="java.lang.Boolean "/> </form-bean> <form-beans>
The declarative properties are what make the ActionForm dynamic. At runtime, the framework creates an instance of the DynaActionForm class and makes it possible to set and get the configured property values. To add new properties, you only need to modify the configuration file; no source code needs to be changed. This provides immense power and flexibility.
As Chapter 4 outlined, the form-property element also allows you to specify the initial value for each property. The framework sets the property to that value when the application is started. The initial value also is used when the reset() method is called to reset the values back to their original states.
Unlike with the ActionForm class, where the default behavior for reset() does nothing, the reset() method in the DynaActionForm class resets all the properties back to their initial values. If you don't include the initial attribute for a property, it will be assigned a default value based on the Java programming language's conventions: numbers will be reset to zero (0) and properties of type Object will be reset to null.
7.5.2 Performing Validation with the DynaActionForm
The DynaActionForm doesn't provide any default behavior for the validate() method. Unless you subclass the DynaActionForm class and override the validate() method, there's no easy way to validate using the DynaActionForm. Fortunately, the framework comes to your aid again with a feature called the Struts Validator.
The Struts Validator was created by David Winterfeldt and is now in the main Struts distribution. The Validator is a framework that was intended to work with Struts from the beginning. It supports basic validation rules such as checking for required fields, email, date and time fields, and many others. One of the biggest benefits is that it provides many of the validation rules that web applications need to perform. It is also very easy to create your own validation rules. The Struts Validator will be covered in Chapter 11.