Requirements

Editorial users must be able to adjust site behavior by editing content without the need to change the code base and redeploy the application. For example:

Administrative users must be able to adjust more technical settings through content, for example:

Solution

CoreMedia Blueprint uses Markup properties following the CoreMedia Struct XML grammar to store settings. Struct XML offers flexible ways to conveniently store typed key-value pairs where the keys are Strings and the values can be any of the following: String, Integer, Boolean, Link, Struct (allows for nested sub Structs).

For more information on the Structs and CoreMedia Struct XML see Section 4.4.4, “Structs” in Unified API Developer Manual.

Settings can be defined on all content types inheriting from CMLinkable.

The local settings are easiest to edit. However, if you want to share common settings across multiple contents, you should spend the few extra steps to put them into a separate Settings document and add it to the linked settings in order to facilitate maintenance and ensure consistency. Some projects make use of settings quite extensively.

Multiple Settings documents are a good instrument to structure settings of different aspects. You can still override single settings in the local settings, which have higher precedence.

The application also considers settings of the content's page context. If you declare a setting in a page, it is effective for all contents rendered in the context of this page.

Settings are inherited down the page hierarchy, so especially settings of the root page are effective for the whole site, unless they are overridden in a subpage or a content.

For more detailed information and customization of the settings lookup strategy see Section 4.4.1.2, “The Settings Service” and the SettingsService related API documentation.

Settings as Java Resource Bundles

In a typical web application there is the need to separate text messages (such as form errors or link texts) from the rendering templates as well as rendering them according to a certain locale. The Spring framework provides a solution for these needs by the concepts of org.springframework.context.MessageSource for retrieving localized messages and by org.springframework.web.servlet.LocaleResolver for retrieving the current locale. Certain JSP tags such as <form:error%gt; or <spring:message> are built on top of these concepts.

In CoreMedia Blueprint, localized messages are stored as settings in Structs as described above and can be accessed as java.util.ResourceBundle instances.

A handler interceptor (com.coremedia.blueprint.cae.web.i18n.ResourceBundleInterceptor) is used to make these content backed messages (as well as the current locale) available to the rendering engine: They are extracted from the content and passed to a special Spring MessageSource, the RequestMessageSource by storing it in the current request. As a consequence, using JSP tags like <spring:message>, <form:error> or <fmt:message> will transparently make use of these messages.