public class InternalResourceViewResolver extends UrlBasedViewResolver
UrlBasedViewResolver that supports
InternalResourceView (i.e. Servlets and JSPs) and subclasses
such as JstlView.
The view class for all views generated by this resolver can be specified
via UrlBasedViewResolver.setViewClass(java.lang.Class<?>). See UrlBasedViewResolver's javadoc for details.
The default is InternalResourceView, or JstlView if the
JSTL API is present.
BTW, it's good practice to put JSP files that just serve as views under WEB-INF, to hide them from direct access (e.g. via a manually entered URL). Only controllers will be able to access them then.
Note: When chaining ViewResolvers, an InternalResourceViewResolver always needs to be last, as it will attempt to resolve any view name, no matter whether the underlying resource actually exists.
UrlBasedViewResolver.setViewClass(java.lang.Class<?>),
UrlBasedViewResolver.setPrefix(java.lang.String),
UrlBasedViewResolver.setSuffix(java.lang.String),
UrlBasedViewResolver.setRequestContextAttribute(java.lang.String),
InternalResourceView,
JstlViewFORWARD_URL_PREFIX, REDIRECT_URL_PREFIXDEFAULT_CACHE_LIMITloggerHIGHEST_PRECEDENCE, LOWEST_PRECEDENCE| Constructor and Description |
|---|
InternalResourceViewResolver()
Sets the default
view class to requiredViewClass():
by default InternalResourceView, or JstlView if the JSTL API
is present. |
InternalResourceViewResolver(String prefix,
String suffix)
|
| Modifier and Type | Method and Description |
|---|---|
protected AbstractUrlBasedView |
buildView(String viewName)
Creates a new View instance of the specified view class and configures it.
|
protected Class<?> |
requiredViewClass()
This resolver requires
InternalResourceView. |
void |
setAlwaysInclude(boolean alwaysInclude)
Specify whether to always include the view rather than forward to it.
|
applyLifecycleMethods, canHandle, createView, getAttributesMap, getCacheKey, getContentType, getExposeContextBeansAsAttributes, getExposedContextBeanNames, getExposePathVariables, getOrder, getPrefix, getRedirectHosts, getRequestContextAttribute, getSuffix, getViewClass, getViewNames, initApplicationContext, isRedirectContextRelative, isRedirectHttp10Compatible, loadView, setAttributes, setAttributesMap, setContentType, setExposeContextBeansAsAttributes, setExposedContextBeanNames, setExposePathVariables, setOrder, setPrefix, setRedirectContextRelative, setRedirectHosts, setRedirectHttp10Compatible, setRequestContextAttribute, setSuffix, setViewClass, setViewNamesclearCache, getCacheLimit, isCache, isCacheUnresolved, removeFromCache, resolveViewName, setCache, setCacheLimit, setCacheUnresolvedgetServletContext, getTempDir, getWebApplicationContext, initApplicationContext, initServletContext, isContextRequired, setServletContextgetApplicationContext, getMessageSourceAccessor, obtainApplicationContext, requiredContextClass, setApplicationContextpublic InternalResourceViewResolver()
view class to requiredViewClass():
by default InternalResourceView, or JstlView if the JSTL API
is present.protected Class<?> requiredViewClass()
InternalResourceView.requiredViewClass in class UrlBasedViewResolverAbstractUrlBasedViewpublic void setAlwaysInclude(boolean alwaysInclude)
Default is "false". Switch this flag on to enforce the use of a Servlet include, even if a forward would be possible.
protected AbstractUrlBasedView buildView(String viewName) throws Exception
UrlBasedViewResolverSpring lifecycle methods as defined by the bean container do not have to
be called here; those will be applied by the loadView method
after this method returns.
Subclasses will typically call super.buildView(viewName)
first, before setting further properties themselves. loadView
will then apply Spring lifecycle methods at the end of this process.
buildView in class UrlBasedViewResolverviewName - the name of the view to buildException - if the view couldn't be resolvedUrlBasedViewResolver.loadView(String, java.util.Locale)