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:
Enable/disable comments for a certain section or the whole site.
Set the number of dynamically determined related content items that are shown in an article detail view.
Configure the refresh interval for content included from an external live source.
Administrative users must be able to adjust more technical settings through content, for example:
Manage API keys for external services
Image rendering settings
Localization of message bundles
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 please see the chapter Structs in the [CoreMedia Unified API Developer Manual]
Settings can be defined on all content types inheriting from CMLinkable.
localSettings
| |
| UI-Name | Local Settings |
| Description |
The settings defined specifically on this
CMLinkable.
|
linkedSettings
| |
| UI-Name | Linked Settings |
| Description |
A list of reusable CMSettings documents that
contain a bundle of settings.
|
Table 6.10. Properties of CMLinkable for Settings Management
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.3.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.
 |  |  |
 |