Spring MVC(1) basic controller work flow

1)DispatcherServlet: the main servlet
org.openmrs.web

2)Controllers
SimpleFormController

Workflow from: http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/web/portlet/mvc/AbstractFormController.html#workflow

1)The controller receives a request for a new form (typically a Render Request only). The render phase will proceed to display the form as follows.

2)Call to formBackingObject() which by default, returns an instance of the commandClass that has been configured (see the properties the superclass exposes), but can also be overridden to e.g. retrieve an object from the database (that needs to be modified using the form).

3) Call to initBinder() which allows you to register custom editors for certain fields (often properties of non- primitive or non-String types) of the command class. This will render appropriate Strings for those property values, e.g. locale-specific date strings.

4)The PortletRequestDataBinder gets applied to populate the new form object with initial request parameters and the onBindOnNewForm(RenderRequest, Object, BindException) callback method is invoked. (only if bindOnNewForm is set to true) Make sure that the initial parameters do not include the parameter that indicates a form submission has occurred.

5)Call to showForm to return a View that should be rendered (typically the view that renders the form). This method has to be implemented in subclasses.

6)The showForm() implementation will call referenceData, which you can implement to provide any relevant reference data you might need when editing a form (e.g. a List of Locale objects you're going to let the user select one from).

7)Model gets exposed and view gets rendered, to let the user fill in the form.

8)The controller receives a form submission (typically an Action Request). To use a different way of detecting a form submission, override the isFormSubmission method. The action phase will proceed to process the form submission as follows.

9)If sessionForm is not set, formBackingObject is called to retrieve a form object. Otherwise, the controller tries to find the command object which is already bound in the session. If it cannot find the object, the action phase does a call to handleInvalidSubmit which - by default - tries to create a new form object and resubmit the form. It then sets a render parameter that will indicate to the render phase that this was an invalid submit.

10)Still in the action phase of a valid submit, the PortletRequestDataBinder gets applied to populate the form object with current request parameters.

11)Call to onBind(PortletRequest, Object, Errors) which allows you to do custom processing after binding but before validation (e.g. to manually bind request parameters to bean properties, to be seen by the Validator).

12)If validateOnBinding is set, a registered Validator will be invoked. The Validator will check the form object properties, and register corresponding errors via the given Errors object.

13)Call to onBindAndValidate which allows you to do custom processing after binding and validation (e.g. to manually bind request parameters, and to validate them outside a Validator).

14)Call to processFormSubmission to process the submission, with or without binding errors. This method has to be implemented in subclasses and will be called only once per form submission.

15)The portal will then call the render phase of processing the form submission. This phase will be called repeatedly by the portal every time the page is refreshed. All processing here should take this into account. Any one-time-only actions (such as modifying a database) must be done in the action phase.

16)If the action phase indicated this is an invalid submit, the render phase calls renderInvalidSubmit which – also by default – will render the results of the resubmitted form. Be sure to override both handleInvalidSubmit and renderInvalidSubmit if you want to change this overall behavior.

17)Finally, call renderFormSubmission to render the results of the submission, with or without binding errors. This method has to be implemented in subclasses and will be called repeatedly by the portal.

Workflow (in addition to the superclass):
1)Call to processFormSubmission which inspects the Errors object to see if any errors have occurred during binding and validation.
2)If errors occured, the controller will return the configured formView, showing the form again (possibly rendering according error messages).
3)If isFormChangeRequest is overridden and returns true for the given request, the controller will return the formView too. In that case, the controller will also suppress validation. Before returning the formView, the controller will invoke onFormChange(javax.portlet.ActionRequest, javax.portlet.ActionResponse, java.lang.Object, org.springframework.validation.BindException), giving sub-classes a chance to make modification to the command object. This is intended for requests that change the structure of the form, which should not cause validation and show the form in any case.
4)If no errors occurred, the controller will call onSubmitAction during the action phase and then onSubmitRender during the render phase, which in case of the default implementation delegate to onSubmitAction and onSubmitRender with just the command object. The default implementation of the latter method will return the configured successView. Consider just implementing doSubmitAction for simply performing a submit action during the action phase and then rendering the success view during the render phase.