This version is still in development and is not considered stable yet. For the latest stable version, please use Spring Framework 6.0.25! |
View Resolution
Spring MVC defines the ViewResolver
and View
interfaces that let you render
models in a browser without tying you to a specific view technology. ViewResolver
provides a mapping between view names and actual views. View
addresses the preparation
of data before handing over to a specific view technology.
The following table provides more details on the ViewResolver
hierarchy:
ViewResolver | Description |
---|---|
|
Subclasses of |
|
Simple implementation of the |
|
Convenient subclass of |
|
Convenient subclass of |
|
Implementation of the |
|
Implementation of the |
Handling
You can chain view resolvers by declaring more than one resolver bean and, if necessary, by
setting the order
property to specify ordering. Remember, the higher the order property,
the later the view resolver is positioned in the chain.
The contract of a ViewResolver
specifies that it can return null to indicate that the
view could not be found. However, in the case of JSPs and InternalResourceViewResolver
,
the only way to figure out if a JSP exists is to perform a dispatch through
RequestDispatcher
. Therefore, you must always configure an InternalResourceViewResolver
to be last in the overall order of view resolvers.
Configuring view resolution is as simple as adding ViewResolver
beans to your Spring
configuration. The MVC Config provides a dedicated configuration API for
View Resolvers and for adding logic-less
View Controllers which are useful for HTML template
rendering without controller logic.
Redirecting
The special redirect:
prefix in a view name lets you perform a redirect. The
UrlBasedViewResolver
(and its subclasses) recognize this as an instruction that a
redirect is needed. The rest of the view name is the redirect URL.
The net effect is the same as if the controller had returned a RedirectView
, but now
the controller itself can operate in terms of 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.
Forwarding
You can also use a special forward:
prefix for view names that are
ultimately resolved by UrlBasedViewResolver
and subclasses. This creates an
InternalResourceView
, which does a RequestDispatcher.forward()
.
Therefore, this prefix is not useful with InternalResourceViewResolver
and
InternalResourceView
(for JSPs), but it can be helpful if you use another view
technology but still want to force a forward of a resource to be handled by the
Servlet/JSP engine. Note that you may also chain multiple view resolvers, instead.
Content Negotiation
ContentNegotiatingViewResolver
does not resolve views itself but rather delegates
to other view resolvers and selects the view that resembles the representation requested
by the client. The representation can be determined from the Accept
header or from a
query parameter (for example, "/path?format=pdf"
).
The ContentNegotiatingViewResolver
selects an appropriate View
to handle the request
by comparing the request media types with the media type (also known as
Content-Type
) supported by the View
associated with each of its ViewResolvers
. The
first View
in the list that has a compatible Content-Type
returns the representation
to the client. If a compatible view cannot be supplied by the ViewResolver
chain,
the list of views specified through the DefaultViews
property is consulted. This
latter option is appropriate for singleton Views
that can render an appropriate
representation of the current resource regardless of the logical view name. The Accept
header can include wildcards (for example text/*
), in which case a View
whose
Content-Type
is text/xml
is a compatible match.
See View Resolvers under MVC Config for configuration details.