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:
ViewResolver | Description |
---|---|
|
|
|
A simple implementation of the |
|
A convenience subclass of |
|
A convenience subclass of |
|
An implementation of the |
|
An implementation of the |
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.