Spring

Spring MVC
http://mhimu.wordpress.com/2007/11/27/spring-mvc-tutorial/

1. Lifecycle of a request in Spring MVC

2. A request leaves the browser asking for a URL and optionally with request parameters.
3. The request is first examined by DispatcherServlet.
4. DispatcherServlet consults handler-mappings defined in a configuration file and selects an appropriate
   controller and delegates to it to handle the request.
5. The controller applies appropriate logic to process the request which results in some information (a.k.a.
   model). This information is associated with the logical name of a result rendering entity (a.k.a view) and the
   whole is returned as a ModelAndView object along with the request back to DispatcherServlet.
6. DispatcherServlet then consults the logical view name with a view resolving object to determine the actual view
   implementation to use.
7. DispatcherServlet delivers the model and request to the view implementation which renders an output and sends it
   back to the browser.

2.Handling Forms

AbstractController is good for hiding Java Servlet specifics but they don’t free you from dealing with raw HTTP requests and responses. Spring MVC gives you AbstractFormController and SimpleFormController that can deal with form display, submission, and processing. SimpleFormController lets you configure various aspects through XML while the former doesn’t.

To understand form processing in Spring MVC, you will add a loan calculator to your web application. For this, you need:

1. A page to be displayed where the user inputs the required parameters (form view)
2. A JavaBean where the input parameters will be mapped (form object)
3. An input validating entity for user mistakes (validator)
4. A page to display the results for a successful execution with valid input (success view)

3.  SimpleFormController

It is better if you understand the workflow of the SimpleFormController. Here is the workflow adapted from Spring API documentation in relevance to this tutorial:

1. Receive a GET request for the form input page
2. Instantiate the form object, i.e. the binding object for parameter mapping
3. The form view is sent to the browser for user input
4. Use submits form (using a GET with parameters or a POST)
5. Populate the form object based on the request parameters (applying necessary conversions from String to
   appropriate object type); in case of binding errors, they are reported through an Errors object
6. If binding is ok and a validator is attached then it is called to validate the form object; in case of errors,
   they are reported through an Errors object
7. If errors are present associated with the model then form view is resent to the browser
8. If validation passes then a chain of onSubmit() methods is called (one of which should be overridden) that
   returns the success view by default

There are multiple submit processing methods of which one you must override depending on the task at hand. In general, override

• ModelAndView onSubmit(HttpServletRequest, HttpServletResponse, Object, BindException) if you want complete
  control on what to return
• ModelAndView onSubmit(Object, BindException) if you want custom submission handling but don’t need to work with
  request and response objects
• ModelAndView onSubmit(Object) if you need nothing more than the input but may return a custom view
• void doSubmitAction(Object) if you don’t need to determine the success or error view