ResourceBundleViewResolver

<init>

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.

DEFAULT_BASENAME

The default basename if no other basename is supplied.

afterPropertiesSet

Eagerly initialize Locales if necessary.

destroy

Close the bundle View factories on context shutdown.

getOrder

setBasename

Set a single basename, following java.util.ResourceBundle conventions. The default is "views".

ResourceBundle supports different suffixes. For example, a base name of "views" might map to ResourceBundle files "views", "views_en_au" and "views_de".

Note that ResourceBundle names are effectively classpath locations: As a consequence, the JDK's standard ResourceBundle treats dots as package separators. This means that "test.theme" is effectively equivalent to "test/theme", just like it is for programmatic java.util.ResourceBundle usage.

setBasenames

Set an array of basenames, each following java.util.ResourceBundle conventions. The default is a single basename "views".

ResourceBundle supports different suffixes. For example, a base name of "views" might map to ResourceBundle files "views", "views_en_au" and "views_de".

The associated resource bundles will be checked sequentially when resolving a message code. Note that message definitions in a previous resource bundle will override ones in a later bundle, due to the sequential lookup.

Note that ResourceBundle names are effectively classpath locations: As a consequence, the JDK's standard ResourceBundle treats dots as package separators. This means that "test.theme" is effectively equivalent to "test/theme", just like it is for programmatic java.util.ResourceBundle usage.

setBundleClassLoader

Set the ClassLoader to load resource bundles with. Default is the thread context ClassLoader.

setDefaultParentView

Set the default parent for views defined in the ResourceBundle.

This avoids repeated "yyy1.(parent)=xxx", "yyy2.(parent)=xxx" definitions in the bundle, especially if all defined views share the same parent.

The parent will typically define the view class and common attributes. Concrete views might simply consist of an URL definition then: a la "yyy1.url=/my.jsp", "yyy2.url=/your.jsp".

View definitions that define their own parent or carry their own class can still override this. Strictly speaking, the rule that a default parent setting does not apply to a bean definition that carries a class is there for backwards compatibility reasons. It still matches the typical use case.

setLocalesToInitialize

Specify Locales to initialize eagerly, rather than lazily when actually accessed.

Allows for pre-initialization of common Locales, eagerly checking the view configuration for those Locales.

setOrder