Page History
...
This page describes the Magnolia-specific directives !inherit, !include and !override . You can use these directives to reuse configuration in YAML file-based configuration. !include is supposed to be used when reusing an arbitrary resource, whereas !inherit comes handy when extending a definition.
Table of Contents maxLevel 4 minLevel 2
| Anchor | ||||
|---|---|---|---|---|
|
YAML include
UseUse !include to add a reusable chunk. Include a YAML fragment on a sub-level of your new definition or include a complete YAML definition on top of your new definition. You can also modify the included part of the definition.
Reference the file you want to include by its resource path. The path to such a resource has the following pattern: /<module-name>/path/to/the/reusable/chunk.yaml .
| Bestpractice |
|---|
Typically, you include YAML snippets which are not a proper definition. Do not add these snippets to the folders which are meant for definitions (templates, dialogs, app). Instead, add these snippets to a folder which is not scanned, for instance |
| Tip |
|---|
If your |
| Anchor | ||||
|---|---|---|---|---|
|
...
The !include directive exists since Magnolia 5.4, which introduced configuration by YAML. With the release of 5.5.6, the directive's syntax has changed slightly. While the old syntax still works, the new one makes it possible to modify and override the included part of the definition. The new syntax uses a colon : instead of the space between !include and the path to the resource.
| Syntax | Requires version | Functions | |
|---|---|---|---|
| Deprecated syntax. | !include <path/to/a–ressource.yaml> | Magnolia 5.4+ | simple include |
| New syntax. | !include:<path/to/a–ressource.yaml> | Magnolia 5.5.6+ | simple include, include and modify |
...
- Prepare a fragment of definition which is suitable to be reused in many other item definitions.
- Include a resource with the
!includedirective. The included resource can contain a fragment or a complete definition. - Modify parts of the included definition.
...
As the name suggests, with this directive you inherit from an existing registered definition item in order to create a new definition item. Registered items can originate from YAML files, JCR configurations or even from Blossom Java Java code.
| Warning |
|---|
It is not a good idea to inherit from a definition which resides in the same module as the dependent one. This can lead to inconsistencies. |
You can inherit only on the root level - which means you can inherit a complete app but not a subapp. Modify the new item according to your needs.
Registered definition items are known to a registry and can be seen in the the Definitions app. Every registered definition item has an "identifier" which is unique among all items of the same type within their registry. Some of the items are defined by name, others by ID. Reference the item to inherit by its identifier.
Inherited items are inherited according to their state known by the registry. (For instance, if if an items has been decorated, the registry knows its decorated state. Hence inheriting a decorated item inherits the decorated state of the item.)
...
The original definition you inherit from:
| Code Pro | ||||||
|---|---|---|---|---|---|---|
| ||||||
...
By setting this dependency, we make sure that module-a is loaded before module-b . As a result, the b-component , which depends on a-component , can can be initialized properly.
| Anchor | ||||
|---|---|---|---|---|
|
...
| Info |
|---|
The |
Example:
| A definition to inherit or to include | Inherit | Inherit and override | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
| |||||||||||||||||||||||||||
The resulting definition merges the inherited defintion and the modifications area, giving five available components in the main area. | The resulting definition ignores all the properties of availableComponents of the inherited definition, thus allowing only one available component in the main area. |
...
| Tip |
|---|
Due to the syntax of a YAML list, you cannot apply |
Example:
| A definition to inherit or to include | Inherit | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| ||||||||||||||||||
Both tabs and fields are defined with a list. To define these properties, it would have been valid to use the map syntax instead. | To apply !override to the tabMeta tab and the title field, we have used the map syntax here. |
...
(Magnolia 5.7.1+) The order of nodes as defined in a decoration via YAML !override is is preserved. This is useful especially if the only change needed to the existing configuration of nodes is their order. Previously, when providing a new config with the !override flag, the config would be picked up by the system, but any change in the order of the nodes (at the level of the !override) would not be respected.
For example, the list view in the workbench of the Tours app may be adjusted with the following definition decoration placing the Path column column before the Name columncolumn:
| Code Block | ||||
|---|---|---|---|---|
| ||||
subApps:
browser:
workbench:
contentViews:
list:
columns: !override
path:
name: |
...
Overview
Content Tools