Magnolia 5.4 reached end of life on November 15, 2018. This branch is no longer supported, see End-of-life policy.
Definition decoration is a Magnolia mechanism which allows you to alter existing configured items, such as apps, dialogs, field types, templates and more. Magnolia 5.4.6+
This page explains the definition decoration concept and provides usage examples.
Definition decoration is a mechanism that allows you to change the properties and subdefinitions of an existing definition.
It is possible to change definitions such as app descriptors, dialogs, field types, message views, templates, media editors and renderer definitions. In short, any definition bound to a Registry (e.g. TemplateDefinitionRegistry ) can be decorated.
Decorated definitions can originate from any source, including the JCR, YAML files or even executable code like Blossom. However, decorators themselves can only be defined via YAML for the time being.
*) A Magnolia Maven module is a Maven packaged module which contains a Magnolia Module descriptor.
**) The Module descriptor defines Module dependencies. If
module-a depends on
module-b, module-b is loaded before module-a. The module dependencies of all Magnolia Maven modules together define a distinct order.
Definition decorator files must be stored in the
decorations folder of a module. The module can be either a Maven module or a light module (see Module structure). This means that it is possible to decorate definitions using the light development approach.
The definition decorator resolution mechanism requires decorator file paths correspond to the following pattern:
<decorating-module-name>: Module which declares the definition decorator.
decorations: Decorations folder within the decorating module.
<target-module-name>: Name of the module that hosts the targeted items to decorate.
<definition-type>: Title of the registry containing definitions, such as apps, dialogs, fieldTypes, messageViews, templates, mediaEditors and renderers.
<def-relative-path>: Path to the decorated definition within the target module, such as
<def-name>: Name of the decorated definition, e.g. pages for the name of an app.
<path-within-definition>: Path of the decorated subdefinition, such as
|Magnolia maven module||Light module|
my-maven-module/ └── src └── main └── resources └── my-module └── decorations ├── dam-app │ └── apps │ └── assets.subApps.browser.contentConnector.yaml ├── mtk │ └── templates │ └── pages │ ├── basic.cssFiles.yaml │ └── basic.yaml └── pages └── apps └── pages.yaml
$magnolia.resources.dir └── my-module └── decorations ├── dam-app │ └── apps │ └── assets.subApps.browser.contentConnector.yaml ├── mtk │ └── templates │ └── pages │ ├── basic.cssFiles.yaml │ └── basic.yaml └── pages └── apps └── pages.yaml
Definition decorator files are loaded in the same way as any other Magnolia resource. See Resources for more. Magnolia's resource change observation mechanism ensures that definition decorators are updated, registered and un-registered in real time, without the necessity of a server restart. (To monitor changes in files coming from the classpath, you must enable the magnolia develop mode, see watching changes of resources).
The effect of a decorator addition, removal or modification is visible on the next decorated definition retrieval attempt.
label: My pages ... icon: icon-user-me
(Screenshot was taken from the definition-app which shows definition items read from the corresponding registry.)
basicMTK page template
cssFiles: chmStyles: link: /.resources/my-module/css/chm-style.css
chmStyles: link: /.resources/my-module/css/chm-style.css
Please note that you can override properties, but you cannot override a subitem completely. You only can add new properties or subitems to an existing subitem.
To understand the above statement, let's have a look at an example of a (simplified) template definition:
templateScript: /mtk/templates/pages/basic.ftl dialog: mtk:pages/basic renderType: freemarker class: info.magnolia.templating.definition.PageTemplateDefinition cssFiles: normalize: link: /.resources/mtk/css/normalize-3.0.3.css main: link: /.resources/mtk/css/html5boilerplate-main-5.3.0.css video: link: /.resources/mtk/css/video.css
link, but you cannot completely override the
cssFilessubItem. For subitems you can only can add more properties and subItems.
The consequence is that you cannot remove the css file /.resources/mtk/css/normalize-3.0.3.css. However, as a workaround, you could do something like this:
normalize: link: ""