If you’ve made it this far, the Controllerwill assemble the full model with the form object,
any possible errors from potential binding, and the model from referenceData(). It will then
send this combined model to the Viewnamed by the formViewproperty. This is the name of the
Viewthat contains the actual HTML form.
Form Submission with SimpleFormController
The SimpleFormControllerhas completed half of its job by displaying the HTML form to the
user. Once the user hits the submit button of the form, the SimpleFormControllerroars back
to life to handle the submission. It will bind the request parameters to the form bean, validate
the bean, and choose to show either the original form again if there were errors or the form
success view if everything worked as expected. We will walk you through this process now,
pointing out the useful life cycle callback methods along the way.
The first method in this controller that determines the form bean’s fate is again the
isFormSubmission()method. Your HTML forms shoulduse the POST method for form submis-
sions for both technical (it can handle much more data) and architectural (POST actions are
intrinsically non-idempotent) reasons. Also, the default implementation of isFormSubmission()
returns trueif the action is a POST. You are free to override this method to further define what a
form submission looks like, but the default should work fine for most situations.
In this case, because we are tracking the form submission work flow, this method will
return true. The SimpleFormControllerwill now check whether or not the form bean is stored
in the session, via the isSessionForm()method. If the form bean is stored in the session, then
the Controllerwill retrieve the form bean, put there originally when the user viewed the form.
The Controllerthen removes the form bean from the session, as it is likely the form bean will
be successfully submitted during this work flow (thus no longer needed in the session). If, in
fact, there are errors during the submission process, the form bean will be placed back into
the session later.
If the form bean was not stored in the session, then the controller will simply create
another instance of the form bean using the formBackingObject()method. This is the same
method used to create the form bean during the initial form view.
■Tip If your form bean requires dependencies to be injected by Spring’s ApplicationContext,overriding
formBackingObject()provides the opportunity to request the bean from the BeanFactory.Of course, to
avoid having to manually pull the bean using the getBean()method on the BeanFactoryyou can use
Spring’s support for method injection (refer to Pro Springby Rob Harrop and Jan Machacek (Apress, 2005)
for more information). In any case, don’t restrict your form beans to simple POJOs as you may use Spring’s
dependency injection for your form beans quite easily.
At this point, the form bean instance has been obtained. The Controllernow creates the
DataBinderand calls the initBinder()callback method. As with the work flow for viewing
the form, use this method to register any custom PropertyEditors you need during binding.
CHAPTER 6 ■THE CONTROLLER MENAGERIE 153