AbstractTemplateViewResolver

Abstract base class for template view resolvers, in particular for FreeMarker views.

Provides a convenient way to specify AbstractTemplateView's exposure flags for request attributes, session attributes, and Spring's macro helpers.

BeanNameViewResolver

A simple implementation of org.springframework.web.servlet.ViewResolver that interprets a view name as a bean name in the current application context, i.e. typically in the XML file of the executing DispatcherServlet.

This resolver can be handy for small applications, keeping all definitions ranging from controllers to views in the same place. For larger applications, XmlViewResolver will be the better choice, as it separates the XML view bean definitions into a dedicated views file.

Note: Neither this ViewResolver nor XmlViewResolver supports internationalization. Consider ResourceBundleViewResolver if you need to apply different view resources per locale.

Note: This ViewResolver implements the Ordered interface in order to allow for flexible participation in ViewResolver chaining. For example, some special views could be defined via this ViewResolver (giving it 0 as "order" value), while all remaining views could be resolved by a UrlBasedViewResolver.

ContentNegotiatingViewResolver

Implementation of ViewResolver that resolves a view based on the request file name or Accept header.

The ContentNegotiatingViewResolver does not resolve views itself, but delegates to other ViewResolvers. By default, these other view resolvers are picked up automatically from the application context, though they can also be set explicitly by using the viewResolvers property. Note that in order for this view resolver to work properly, the order property needs to be set to a higher precedence than the others (the default is Ordered#HIGHEST_PRECEDENCE).

This view resolver uses the requested MediaType to select a suitable View for a request. The requested media type is determined through the configured ContentNegotiationManager. Once the requested media type has been determined, this resolver queries each delegate view resolver for a View and determines if the requested media type is compatible with the view's content type). The most compatible view is returned.

Additionally, this view resolver exposes the defaultViews property, allowing you to override the views provided by the view resolvers. Note that these default views are offered as candidates, and still need have the content type requested (via file extension, parameter, or Accept header, described above).

For example, if the request path is /view.html, this view resolver will look for a view that has the text/html content type (based on the html file extension). A request for /view with a text/html request Accept header has the same result.

DefaultRequestToViewNameTranslator

RequestToViewNameTranslator that simply transforms the URI of the incoming request into a view name.

Can be explicitly defined as the viewNameTranslator bean in a org.springframework.web.servlet.DispatcherServlet context. Otherwise, a plain default instance will be used.

The default transformation simply strips leading and trailing slashes as well as the file extension of the URI, and returns the result as the view name with the configured prefix and a suffix added as appropriate.

The stripping of the leading slash and file extension can be disabled using the stripLeadingSlash and stripExtension properties, respectively.

Find below some examples of request to view name translation.

• http://localhost:8080/gamecast/display.html » display
• http://localhost:8080/gamecast/displayShoppingCart.html » displayShoppingCart
• http://localhost:8080/gamecast/admin/index.html » admin/index

InternalResourceView

Wrapper for a JSP or other resource within the same web application. Exposes model objects as request attributes and forwards the request to the specified resource URL using a javax.servlet.RequestDispatcher.

A URL for this view is supposed to specify a resource within the web application, suitable for RequestDispatcher's forward or include method.

If operating within an already included request or within a response that has already been committed, this view will fall back to an include instead of a forward. This can be enforced by calling response.flushBuffer() (which will commit the response) before rendering the view.

Typical usage with InternalResourceViewResolver looks as follows, from the perspective of the DispatcherServlet context definition:

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/jsp/"/> <property name="suffix" value=".jsp"/> </bean>

JstlView

Specialization of InternalResourceView for JSTL pages, i.e. JSP pages that use the JSP Standard Tag Library.

Exposes JSTL-specific request attributes specifying locale and resource bundle for JSTL's formatting and message tags, using Spring's locale and org.springframework.context.MessageSource.

Typical usage with InternalResourceViewResolver would look as follows, from the perspective of the DispatcherServlet context definition:

 <bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/> <property name="prefix" value="/WEB-INF/jsp/"/> <property name="suffix" value=".jsp"/> </bean> <bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource"> <property name="basename" value="messages"/> </bean>

The specified MessageSource loads messages from "messages.properties" etc files in the class path. This will automatically be exposed to views as JSTL localization context, which the JSTL fmt tags (message etc) will use. Consider using Spring's ReloadableResourceBundleMessageSource instead of the standard ResourceBundleMessageSource for more sophistication. Of course, any other Spring components can share the same MessageSource.

This is a separate class mainly to avoid JSTL dependencies in InternalResourceView itself. JSTL has not been part of standard J2EE up until J2EE 1.4, so we can't assume the JSTL API jar to be available on the class path.

Hint: Set the #setExposeContextBeansAsAttributes flag to "true" in order to make all Spring beans in the application context accessible within JSTL expressions (e.g. in a c:out value expression). This will also make all such beans accessible in plain ${...} expressions in a JSP 2.0 page.

ResourceBundleViewResolver

A org.springframework.web.servlet.ViewResolver implementation that uses bean definitions in a ResourceBundle, specified by the bundle basename.

The bundle is typically defined in a properties file, located in the classpath. The default bundle basename is "views".

This ViewResolver supports localized view definitions, using the default support of java.util.PropertyResourceBundle. For example, the basename "views" will be resolved as class path resources "views_de_AT.properties", "views_de.properties", "views.properties" - for a given Locale "de_AT".

Note: This ViewResolver implements the Ordered interface in order to allow for flexible participation in ViewResolver chaining. For example, some special views could be defined via this ViewResolver (giving it 0 as "order" value), while all remaining views could be resolved by a UrlBasedViewResolver.

XmlViewResolver

A org.springframework.web.servlet.ViewResolver implementation that uses bean definitions in a dedicated XML file for view definitions, specified by resource location. The file will typically be located in the WEB-INF directory; the default is "/WEB-INF/views.xml".

This ViewResolver does not support internationalization at the level of its definition resources. Consider ResourceBundleViewResolver if you need to apply different view resources per locale.

Note: This ViewResolver implements the Ordered interface in order to allow for flexible participation in ViewResolver chaining. For example, some special views could be defined via this ViewResolver (giving it 0 as "order" value), while all remaining views could be resolved by a UrlBasedViewResolver.