spring-framework / org.springframework.web.servlet.view / InternalResourceView

InternalResourceView

open class InternalResourceView : AbstractUrlBasedView

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>

Every view name returned from a handler will be translated to a JSP resource (for example: "myView" -> "/WEB-INF/jsp/myView.jsp"), using this view class by default.

Author
Rod Johnson

Author
Juergen Hoeller

Author
Rob Harrop

Constructors

<init>

InternalResourceView()

Constructor for use as a bean.

InternalResourceView(url: String)
InternalResourceView(url: String, alwaysInclude: Boolean)

Create a new InternalResourceView with the given URL.

Functions

setAlwaysInclude

open fun setAlwaysInclude(alwaysInclude: Boolean): Unit

Specify whether to always include the view rather than forward to it.

Default is "false". Switch this flag on to enforce the use of a Servlet include, even if a forward would be possible.

setPreventDispatchLoop

open fun setPreventDispatchLoop(preventDispatchLoop: Boolean): Unit

Set whether to explicitly prevent dispatching back to the current handler path.

Default is "false". Switch this to "true" for convention-based views where a dispatch back to the current handler path is a definitive error.

Inheritors

JstlView

open class JstlView : InternalResourceView

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>

Every view name returned from a handler will be translated to a JSP resource (for example: "myView" -> "/WEB-INF/jsp/myView.jsp"), using this view class to enable explicit JSTL support.

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.