Table 14-1. Special bean types in WebApplicationContext
|HandlerMapping||This bean is responsible for mapping the request to the correct handler. Based on the type of Handler Mapping implementation, it can have multiple pre and post processors called as Handler Interceptors. We have a dedicated section which explains this bean type in detail.|
|HandlerAdapter||As explained earlier Handler Mapping helps maps a request to the appropriate handler. The complexity involved in handler implementation is usually shielded away from the DispatcherServlet by the Handler Adapter which actually kicks in between and does the complex stuff to find the actual handler.|
|HandlerExceptionResolver||Responsible for mapping the various exceptions to appropriate views and allows handling of more complex exception according to application requirement.|
|ViewResolver||Responsible for resolving string based view names to the actual view types.|
|LocaleResolver||Responsible for checking the client’s locale and rendering locale specific views as necessary.|
|ThemeResolver||Responsible for rendering the view according to various themes built-in.|
|MultipartResolver||Responsible for processing multi-part requests mainly for uploading files from the view layer (HTML forms).|
|FlashMapManager||Responsible for storing and retrieving input and output FlashMap, which can be used for passing attributes between requests mainly in a redirect process.|
Having explained the various special bean types in DispatcherServlet, it’s good to know the actual flow of request through the various DispatcherServlet bean types. These can be summarized as shown below:
- Appropriate WebApplicationContext is found and bound to the request as an attribute which can be made use by other components in the process. It’s stored under the key value DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE.
- LocaleResolver is now bound to the request so that the elements in the process can look into locale and do appropriate processing.
- ThemeResolver is bound to the request so that elements can be rendered according to the theme used by the application.
- Inspects whether the request is multipart, accordingly wrapped around appropriate object so that processing can take place accordingly.
- According to HandlerMapping specified, handler is looked for. If found then appropriate processors associated with this handler is invoked and the model is made ready to be rendered.
- If Model is returned, appropriate view associated with it gets rendered, otherwise nothing gets rendered.
Controller’s responsibility is to interpret the client request, call the service layer if required, create the model object and sends it to the view layer which uses it to render the final output in the browser. Controller acts as the linkage between the client layer and the service layer and is responsible for the data shown on the view.
Spring represents a controller in a very abstract way and has built-in controllers to satisfy almost all the basic controller requirements in a typical web application. In addition to this following the principle, “Open for Extension, Closed for modification”, it allows writing your own controllers by extending these built-in controller classes as required by your web application requirement. Some of the details of controllers are as summarized below:
- AbstractController – Class using Template Method design pattern which can be considered as a convenient superclass your own controller implementation can extend and use. It gives most of the basic controller behavior such as caching and controlling of session.
- ParameterizableViewController – Controller which always returns a named view. In your application if your controller just wants to navigate to a particular view type, using this controller can bring in an indirection by allowing you to avoid the exposing the final view technology from the user and exposing the controller URL, which shields it. The ViewResolver kicks in and finds the right view for the requested resource.
- UrlFileNameViewController – Controller which is very commonly used in which it transforms the virtual path of a URL to the appropriate view name and returns the view. Optionally it can use a prefix or suffix to the URL pattern to derive at the final view to be supplied to the requester.
- SimpleFormController – Deprecated as of Spring 3.0 as annotated controllers can be used rather than extending it from Spring Controller classes which unnecessarily created hooking onto spring in the code level. This controller was used for handling forms, provides hooks for attaching commands and handling of validation errors and resubmitting it as the case may be.
- AbstractWizardFormController – Deprecated as of 3.0 in favor of annotated controller but if you want to use it can be used for wizard-style workflows.
- ServletWrappingController – If you would like to wrap a servlet with a controller, this can be used very effectively. The complete lifecycle of such wrapped servlet resides inside the controller and not know outside of it.
Figure 14-9 below shows the Spring MVC controller class hierarchy.
Figure 14-9. Spring MVC controller class hierarchy
Page Visitors: 6480