Course Module 5. Spring - Lecture: Representation Recognition

Spring MVC defines the ViewResolver and View interfaces that allow you to render models in the browser without committing you to a specific presentation technology. ViewResolver provides a mapping between view names and actual views. View is concerned with preparing data before passing it to a specific presentation technology.

The following table provides more detailed information about the ViewResolver hierarchy:

Table 3. ViewResolver implementations
ViewResolver	Description
`AbstractCachingViewResolver`	`AbstractCachingViewResolver` subclasses cache instances of the views they recognize. Caching improves the performance of certain presentation technologies. You can disable the cache by setting the `cache` property to `false`. Additionally, if you need to update a specific view while the program is running (for example, when the FreeMarker template changes), you can use the `removeFromCache(String viewName, Locale loc)` method.
`UrlBasedViewResolver`	A simple implementation of the `ViewResolver` interface that allows logical view names to be directly resolved into URLs without explicitly defining the view. This is appropriate if your logical names match the names of your view resources in a simple form, without the need for arbitrary mapping.
`InternalResourceViewResolver`	A convenience subclass of `UrlBasedViewResolver` that supports `InternalResourceView` (essentially servlets and JSPs) and subclasses such as `JstlView` and `TilesView` . You can set the view class for all views created by this resolver using `setViewClass(..)`. For details, see the javadoc at `UrlBasedViewResolver`.
`FreeMarkerViewResolver`	A convenience subclass of `UrlBasedViewResolver` that supports `FreeMarkerView` and their custom subclasses.
`ContentNegotiatingViewResolver`	An implementation of the `ViewResolver` interface that recognizes a view based on the request file name or the `Accept` header.
`BeanNameViewResolver`	An implementation of the `ViewResolver` interface that interprets the view name as the name of a bean in the current application context. This is a very flexible option that allows you to mix and match different view types based on different view names. Each such `View` implementation can be defined as a bean, for example in XML classes or configuration classes.

Processing

You can chain view resolvers by declaring more than one resolver bean and optionally setting the order property to specify the order. Remember that the higher the order property, the later in the chain the view resolver is located.

The ViewResolver contract specifies that it can return null to determine that the view cannot be found. However, in the case of JSP and InternalResourceViewResolver, the only way to find out if the JSP exists is to dispatch via RequestDispatcher. Therefore, you should always place the InternalResourceViewResolver in your configuration last in the overall order of view resolvers.

Configuring view resolution is as simple as adding ViewResolver beans to your Spring configuration. MVC Config provides a special configuration API for view resolvers and for adding algorithm-free view controllers, which are useful for rendering HTML template without algorithm control.

Forwarding

The special prefix redirect: in the view name allows you to perform redirection. UrlBasedViewResolver (and its subclasses) recognizes this as a command to perform the necessary redirection. The rest of the view name is the redirect URL.

The end result is the same as if the controller returned RedirectView, but now the controller itself can work with logical view names. A logical view name (such as redirect:/myapp/some/resource) redirects relative to the current servlet context, while a name such as redirect:https://myhost.com/some/arbitrary/path, redirects to an absolute URL.

Note that if a controller method is annotated with @ResponseStatus, the value of the annotation takes precedence over the response status set by RedirectView.

Redirection

You can also use the special prefix forward: for view names, which are ultimately resolved by UrlBasedViewResolver and subclasses. This creates an InternalResourceView that executes RequestDispatcher.forward(). Therefore, this prefix is not useful when using InternalResourceViewResolver and InternalResourceView (for JSP), but it may be useful if you are using a different presentation technology but still need to force the resource to be redirected to processing by servlet/JSP container. Note that it is also possible to chain multiple view resolvers together instead.

Content coordination

ContentNegotiatingViewResolver does not resolve views itself, but delegates this work to other view resolvers and fetches a view that is similar to the one requested by the client. The view can be specified from the Accept header or from a request parameter (for example, "/path?format=pdf").

ContentNegotiatingViewResolver selects the appropriate View to process the request by comparing the request data types with the data type (also known as Content-Type) supported by View associated with each of its ViewResolvers. The first View in the list that has a compatible Content-Type returns the view to the client. If the ViewResolver chain fails to provide a compatible view, the list of views specified in the DefaultViews property is used. This last option is suitable for single Views that can render the corresponding view of the current resource regardless of the logical view name. The Accept header can contain wildcards (for example, text/*), in this case View, whose Content-Type equals text/xml, is compatible.