controller will then consider this request as the first of two requests (the second being the
actual form submission). It will create an instance of the form object (a.k.a. command bean)
using the formBackingObject()method. By default, this method will return an instance of the
class specified with setCommandClass(). The formBackingObject()method is not final, so you
will use this method to configure, if necessary, the form object class, possibly setting any
dependencies or properties. This is the time to manipulate the form object before it enters
the work flow.
Once the instance of the form object is ready, the controller then creates the DataBinder
and calls the initBinder()life cycle method. Override this method to register any custom
PropertyEditors required when binding to the form object. By default, this method does
nothing.
Now that the DataBinderinstance is ready, you have the choice of performing a binding
using any parameters sent with this initial HTTP GET request. This action is determined by the
bindOnNewFormproperty, enabled by (you guessed it) calling the setBindOnNewForm()method.
Typically, on the first view of a form, no parameters have been sent with the request, so it is safe
to leave bindOnNewFormequal to false(the default). However, if you set the property to true,
and any errors occurred from the binding process, those errors will be available to the initial
form view.
The SimpleFormControllerhas the ability to store the form object in the session for the
duration of the controller’s work flow. That is, the form will live in the session between the ini-
tial form view and the form submission. To enable this feature, simply call setSessionForm()
with a value of true. Once the form object has been created, and after it is possibly bound by
the DataBinder, it will be stored in the session if this property is true.
If you load the form bean from persistence using an object-relational mapping (ORM) tool,
you may find the session form functionality useful. Many ORM tools support the concept of
reattaching, or merging, a detached bean back into persistence. If you require this type of behav-
ior, using the session form functionality is a nice way to load the form bean only once during
initial form view. That same instance will then be used during the form submission stage, avoid-
ing the need to pull the instance from persistence again. Most persistence strategies can handle
pulling the instance twice (once on form view and once on form submission), so weigh the pros
with the cons of increased memory usage for the session, among other issues.■CautionStoring the form in the session should not be chosen lightly if the application is to be clustered.
Typically, in a clustered environment, session data is serialized and often replicated among different nodes in
the cluster. Serialization is a costly procedure, and it can place a heavy burden on cluster bandwidth. Check
with your application server’s clustering strategies, and be sure to understand the impact of session storage.At this point, the form view is about to be returned to the user. Before the view is ren-
dered, the referenceData()callback is called. This life cycle method allows you to assemble
and return any auxiliary objects required to render the view. The form object will automati-
cally be sent to the form view, so use this method to put anything else into the model the
form page might need. By default, this method does not manipulate the model in any way.152 CHAPTER 6 ■THE CONTROLLER MENAGERIE