org.springframework.web.servlet.view Documentation Differences

This file contains all the changes in documentation in the package org.springframework.web.servlet.view as colored differences. Deletions are shown like this, and additions are shown like this.

If no deletions or additions are shown in an entry, the HTML tags will be what has changed. The new HTML tags are shown in the differences. If no documentation existed, and then some was added in a later version, this change is noted in the appropriate class pages of differences, but the change is not shown on this page. Only changes in existing text are shown here. Similarly, documentation which was inherited from another class or interface is not shown here.

Note that an HTML error in the new documentation may cause the display of other documentation changes to be presented incorrectly. For instance, failure to close a <code> tag will cause all subsequent paragraphs to be displayed differently.

Enable or disable caching.

This is equivalent to setting the "cacheLimit" property to the default limit (1024) or to 0, respectively.

Default is "true": caching is enabled. Disable this only for debugging and development. Warning: Disabling caching can severely impact performance.

Creates a combined output Map (never null) that includes dynamic values and static attributes. Dynamic values take precedence over static attributes.

Whether to add path variables in the model or not.

Path variables are commonly bound to URI template variables through the {@code @PathVariable} annotation. They're are effectively URI template variables with type conversion applied to to them to derive typed Object values. Such values are frequently needed in views for for constructing links to the same and other URLs.

Path variables added to the model override static attributes (see .setAttributes(Properties)) but not attributes already present in the model.

By default this flag is set to {@code true}. Concrete view types can override this. @param exposePathVariables {@code true} to expose path variables, and {@code false} otherwise.

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

The {@code 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 media type to select a suitable View for a request. This media type is determined by using the following criteria: If theThe requested path has a file extension and if the .setFavorPathExtension property is {@code true}, the mediaTypes property is inspected for a matching media type. If the request contains a parameter defining the extension and if the .setFavorParameter property is true, the mediaTypes property is inspected for a matching media type. The default namedetermined ofthrough the parameter is format and it can be configured using the parameterName property. If there is no match in the mediaTypes property and if the Java Activation Framework (JAF) is both #setUseJaf enabled and present on the classpath, FileTypeMap.getContentType(String) is used instead. If the previous steps did not result in a media type, and ignoreAcceptHeaderContentNegotiationManager is {@code false}, the request {@code Accept} header is used. 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 MediaType#includes(MediaType) compatible with the view's View#getContentType() 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 candicates, and still need have the content type requested (via file extension, parameter, or {@code Accept} header, described above). You can also set the #setDefaultContentType(MediaType) default content type directly, which will be returned when the other mechanisms ({@code Accept} header, file extension or parameter) do not result in a match.

For example, if the request path is {@code /view.html}, this view resolver will look for a view that has the {@code text/html} content type (based on the {@code html} file extension). A request for {@code /view} with a {@code text/html} request {@code Accept} header has the same result. @author Arjen Poutsma @author Juergen Hoeller @author Rossen Stoyanchev @since 3.0 @see ViewResolver @see InternalResourceViewResolver @see BeanNameViewResolver

Determines the list of MediaType for the given HttpServletRequest. The default implementation invokes .getMediaTypeFromFilename(String) if #setFavorPathExtension favorPathExtension property is true. If the property is false, or when a media type cannot be determined from the request path, this method will inspect the {@code Accept} header of the request. This method can be overridden to provide a different algorithm. @param request the current servlet request @return the list of media types requested, if any

Set the default content type.

This content type will be used when file extension, parameter, nor {@code Accept} header define a content-type, either through being disabled or empty. @deprecated use .setContentNegotiationManager(ContentNegotiationManager)

Indicate whether a request parameter should be used to determine the requested media type, in favor of looking at the {@code Accept} header. The default value is {@code false}.

For instance, when this flag is true, a request for {@code /hotels?format=pdf} will result in an {@code AbstractPdfView} being resolved, while the {@code Accept} header can be the browser-defined {@code text/html,application/xhtml+xml}. @deprecated use .setContentNegotiationManager(ContentNegotiationManager)

Indicate whether the extension of the request path should be used to determine the requested media type, in favor of looking at the {@code Accept} header. The default value is {@code true}.

For instance, when this flag is true (the default), a request for {@code /hotels.pdf} will result in an {@code AbstractPdfView} being resolved, while the {@code Accept} header can be the browser-defined {@code text/html,application/xhtml+xml}. @deprecated use .setContentNegotiationManager(ContentNegotiationManager)

Indicate whether the HTTP {@code Accept} header should be ignored. Default is {@code false}.

If set to {@code true}, this view resolver will only refer to the file extension and/or parameter, as indicated by the favorPathExtension and favorParameter properties. @deprecated use .setContentNegotiationManager(ContentNegotiationManager)

Set the mapping from file extensions to media types.

When this mapping is not set or when an extension is not present, this view resolver will fall back to using a FileTypeMap when the Java Action Framework is available. @deprecated use .setContentNegotiationManager(ContentNegotiationManager)

Set the parameter name that can be used to determine the requested media type if the .setFavorParameter property is {@code true}. The default parameter name is {@code format}. @deprecated use .setContentNegotiationManager(ContentNegotiationManager)

Indicate whether to use the Java Activation Framework to map from file extensions to media types.

Default is {@code true}, i.e. the Java Activation Framework is used (if available). @deprecated use .setContentNegotiationManager(ContentNegotiationManager)

View that redirects to an absolute, context relative, or current request relative URL. The URL may be a URI template in which case the URI template variables will be replaced with values available in the model. By default all primitive model attributes (or collections thereof) are exposed as HTTP query parameters (assuming they've not been used as URI template variables), but this behavior can be changed by overriding the .isEligibleProperty(String, Object) method.

A URL for this view is supposed to be a HTTP redirect URL, i.e. suitable for HttpServletResponse's sendRedirect method, which is what actually does the redirect if the HTTP 1.0 flag is on, or via sending back an HTTP 303 code - if the HTTP 1.0 compatibility flag is off.

Note that while the default value for the "contextRelative" flag is off, you will probably want to almost always set it to true. With the flag off, URLs starting with "/" are considered relative to the web server root, while with the flag on, they are considered relative to the web application root. Since most web applications will never know or care what their context path actually is, they are much better off setting this flag to true, and submitting paths which are to be considered relative to the web application root.

NOTE when using this redirect view in a Portlet environment: Make sure that your controller respects the Portlet sendRedirect constraints. When e.g. using org.springframework.web.portlet.mvc.SimpleFormController, make sure to set your controller's "redirectAction" property to "true", in order to make the controller base class behave accordingly. @author Rod Johnson @author Juergen Hoeller @author Colin Sampaleanu @author Sam Brannen @author Arjen Poutsma @author Rossen Stoyanchev @see #setContextRelative @see #setHttp10Compatible @see #setExposeModelAttributes @see javax.servlet.http.HttpServletResponse#sendRedirect

Whether to treat the redirect URL as a URI template. Set this flag to false if the redirect URL contains open and close curly braces "{", "}" and you don't want them interpreted as URI variables.

Defaults to true. @param expandUriTemplateVariables