With the form bean created, and the DataBindercreated with custom PropertyEditors regis-
tered, the request parameters are now bound to the form bean. The binding process will also
capture any binding errors, such as type conversion errors or any configured required fields.
Of course, most forms require more complicated validation than what is provided
by the DataBinder. At this point in the work flow, the Controllerconsults the method
isValidateOnBinding()to determine if it should now run the form bean through the
Validators. This method defaults to true, and it is marked finalso the only way to change
its behavior is through setValidateOnBinding().
If your situation requires a more exact control over when validation is performed after a
binding, you may override the suppressValidation()method. While this method defaults to
false, this method allows you to choose on a request-by-request basis whether or not to run
through the validators.
By default, the controller will allow each configured validator to validate the form bean.
After all the validators have run, the controller will then call the onBindAndValidate()life cycle
method. This callback method is your chance to perform any custom validation logic or gen-
eral logic after binding and validation.■NoteThe onBindAndValidate()method will run even if suppressValidation()returns trueor if
isValidateOnBinding()returns false.In other words,onBindAndValidate()will always run, even if
validation did not.After onBindAndValidate()runs, the Controllermakes a decision based on whether any
errors exist. These errors would have resulted from the binding process or through automatic
validation or custom validation in onBindAndValidate(). If there are any errors, the Controller
then begins the process of displaying the original form. If no errors exist, then the form bean
can finally be processed.
If errors are present and the isSessionForm()method returns true, then the form bean is
placed back into the session. Remember that the form bean is removed from the session at the
beginning of the form submission handling work flow. However, when there are errors, the
original form is displayed again, and so the form bean is stored in the session again to be
bound again once the errors are addressed by the user. The referenceData()method is called
once more to populate the model with objects for the form. Finally, the form view is displayed
again, with the errors and the form bean.
If there are no errors, the controller then calls the onSubmit()life cycle method. This sig-
nals that the form bean is ready to be processed. There are several overloaded onSubmit()
methods, each method simply calling the other with one fewer method argument. This flow,
illustrated in Figure 6-2, is arranged this way to allow you to pick the method with the exact
number of parameters you will need to process the form. There is no need to implement all
onSubmit()methods; just choose the one that will work for you.
There is also a very simple doSubmitAction(), which is the most simple callback method
to override and implement. If you do not implement any of the onSubmit()methods, you will
need to implement this method. This method simply provides the form bean to be processed.
You may use this method when there is no model to construct and when the default success
view is appropriate. If you need to construct a model, or if you need to choose the view to
show dynamically, implement one of the onSubmit()methods.154 CHAPTER 6 ■THE CONTROLLER MENAGERIE