Magnolia 5.7 reached extended end of life on May 31, 2022. Support for this branch is limited, see End-of-life policy. Please note that to cover the extra maintenance effort, this EEoL period is a paid extension in the life of the branch. Customers who opt for the extended maintenance will need a new license key to run future versions of Magnolia 5.7. If you have any questions or to subscribe to the extended maintenance, please get in touch with your local contact at Magnolia.
This page describes Magnolia's main uses of YAML, a data serialization format designed for human readability and interaction with scripting languages:
- Using YAML to define items such as templates, dialogs, and apps.
- Using YAML for exporting and importing JCR content.
The two uses of YAML in Magnolia
Before Magnolia 5.4, the only way to define (configure) templates, dialogs, apps and other definition items was only through JCR in the configuration
workspace. Magnolia 5.4 brought configuration via YAML as another possibility, mainly because:
- YAML is less difficult to work with in typical development cases such as diffing and merging.
- The format is easier to read and edit, the content and overall structure is more readily visible to the user, e.g. importing multi-line quotes and special character needs no escaping.
- It enables easier creation of JCR import files from other data sources.
With the release of Magnolia 5.5.4, importing and exporting JCR data can be done with YAML files. Until then this was possible only in the XML format.
To parse YAML data Magnolia uses snakeyaml. The data is transformed by the info.magnolia.map2bean.Map2BeanTransformer
.
YAML as definition files
YAML files are primarily meant to define (configure) items such as apps, templates, dialogs.
Example: A YAML definition of a helloworld
app.
appClass: info.magnolia.ui.app.helloworld.HelloWorldApp class: info.magnolia.ui.api.app.registry.ConfiguredAppDescriptor icon: icon-app label: Hello World
What can be defined via YAML?
- App definitions
- Dialog definitions
- Field type definitions
- Media editor definitions
- Message view definitions
- Renderer definitions
- REST endpoint definitions
- Template definitions
- Theme definitions
- Virtual URI mappings
- Workflow definitions
- Work item handler definitions
Items defined in the configuration
workspace can be downloaded as YAML to move the configuration into a file.
In a running system, the data written in YAML is represented by a Java Bean. The following table lists Magnolia YAML files and their corresponding Magnolia classes, usually called definition or description classes.
Item | YAML file | Corresponding definition class* |
---|---|---|
Dialog | myDialog.yaml | DialogDefinition |
Template | myTemplate.yaml | TemplateDefinition |
App | myApp.yaml | AppDescriptor |
* You can also use custom definition classes which will usually extend the classes mentioned above. In this case you have to provide the class as an attribute in the YAML file.
Deprecating a YAML-based definition with !metadata
The introduction of the info.magnolia.config.source.yaml.construct.WrapMetadata
construct in Magnolia 5.6.2 allows you to deprecate YAML-based definitions. You can mark a YAML-based definition as deprecated like this:
deprecated: !metadata since: 5.5.6 description: The dialog uses the deprecated PlaceholderTextFieldDefinition. Please use the placeholder property instead.
The deprecated definition is displayed in the Definitions app. Currently, the app reports the following deprecated (or non-existing) items:
- Deprecated classes used by any definition.
- Deprecated or non-existing templates used by block definitions.
- Deprecated or non-existing page template definitions referenced from site definitions.
- Deprecated or non-existing theme definitions referenced from site definitions.
- Template references.
- Deprecated or non-existing dialogs
- Deprecated or non-existing component definitions used in page definitions.
- Non-existing template script paths.
- Configured but non-existing renderer.
Reusing configuration in YAML files with !inherit
and !include
Magnolia provides two mechanisms to reuse a configuration within a YAML-file:
!inherit
and !include
. You can use them not only to reuse a definition but also to modify a reused definition.
YAML inherit
Use the Magnolia !inherit
directive to inherit a registered definition item in order to create a new definition item, and then modify the new item according to your needs. This directive is very similar to JCR extends. The item you inherit the definition from is referenced by its identifier.
Example:
The new renderer named !inherit:freemarker
contentType: application/json
json
inherits everything from the freemarker
renderer but has a different contentType.
Reference a field by its name
Instead of defining the type of a field using the class
property, you can reference the type using the fieldType
property, which takes the field's short and easy-to-remember alias name as the value.
For example, use fieldType: text
instead of class: info.magnolia.ui.form.field.definition.TextFieldDefinition
.
To view the field alias names, look in the Definitions app. See also Referencing fields.
For more information read the YAML inherit and include page.
YAML include
Use the Magnolia !include
directive to add a reusable YAML chunk. Include a fragment on a sub-level of your new definition or include a complete definition on top of your new definition. Reference the file you include by its resource path. The path to such a resource has the following pattern: /<module-name>/path/to/the/reusable/chunk.yaml
.
You can also modify the included part of the definition.
If your !include
file is not working, check that the first line in the included YAML file does not have any indentation.
Syntactic variants of the directive
The !include
directive exists since Magnolia 5.4, which introduced configuration by YAML. However, the directive's syntax has changed slightly with the release of Magnolia 5.5.6. 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 |
Example:
form:
label: lazy-component
tabs:
# an include within a list, here adding a complete tab
- !include:/module-a/includes/categorization-tab.yaml
label: Yo! 1-tab-only!
fields:
# modify properties of the field blackOrWhite which comes from the include
- name: blackOrWhite
label: Choose color
# an include within a map, here adding the actions for the root (map) item "actions"
actions: !include:/module-a/includes/common-actions.yaml
# add another action to those which already exist from the include
doit:
label: Same as cancel
class: info.magnolia.ui.admincentral.dialog.action.CancelDialogActionDefinition
blackOrWhite
field from the include.
For more information read YAML inherit and include.
YAML override
Use !override
to completely ignore the properties of an inherited or included node. As a consequence, you have to add specify properties to the given node.
Reusing an existing definition within the same file
YAML's anchor property and alias indicator make it possible to reuse an already existing definition by referencing it. In the following definition snippet see, for example, the anchor &footerAvailableComponents
(line 5) and the alias *footerAvailableComponents
(line 14), which allow reusing the components defined in the footer
area also in the main
area:
Definition decoration
With some restrictions related to overriding properties and changing subitems, YAML is currently the only way to decorate already existing definitions. For more details see Definition decoration page.
Defining a list property via YAML map or list syntax
In a YAML file, when a property type is defined as a list in the corresponding Java class, you can use the map syntax or the list syntax. Map2BeanTransformer converts YAML in both cases correctly.
Java definition class
public interface TabDefinition<T> extends NamedDefinition<T> { List<NamedFieldDefinition> getFields(); }
name
property.List syntax
mainTab: fields: - name: salutation fieldType: text - name: firstName label: first name fieldType: text
name
sub-property.Map syntax
mainTab: fields: salutation: label: salutation fieldType: text firstName: name: givenName label: first name fieldType: text
name
property by Map2BeanTransformer. You can override it by setting the name
property explicitly (line 7).YAML for importing and exporting JCR content
YAML can also be used to export and import JCR content, which was originally possible only with XML files.
Example: An export of a simple page node in YAML format
Syntax
For a complete reference of the YAML syntax please refer to http://yaml.org/ or http://www.yaml.org/refcard.html. The following syntactic elements are the most widely used though.
- Whitespace indentation is used to denote structure; however tab characters are never allowed as indentation.
- Comments begin with the number sign (
#
), can start anywhere on a line and continue until the end of the line. Comments must be separated from other tokens by white space characters. - Strings (scalars) are ordinarily unquoted, but may be enclosed in double-quotes (
"
), or single-quotes ('
).
Sequences
Members of a sequence are lines beginning at the same indentation level, and starting with a leading hyphen and at least one space ( -
). The number of spaces after the leading hyphen must be the same for all members in the sequence.
# A list of food - Sandwich - Pizza - Burrito - Chocolate cake
Mappings
Mappings (also known as dictionaries in YAML, or just maps informally) are represented in a simple
key: value
form (the colon must be followed by a space):
# An employee record name: John Doe job: Developer skill: Beginner
Combinations of mappings and sequences
Let's combine some mappings and sequences, which is a common use case in Magnolia YAML files.
--- # An employee record name: John Doe job: Developer skill: Beginner employed: True food: - Sandwich - Pizza - Burrito - Chocolate cake drinks: [coke, beer, water, milk] # this is an example of another notation for a sequence languages: groovy: Beginner java: Beginner freeMarker: Expert
Note:
- The root structure of this file is a mapping.
- The values of the
food
anddrinks
mappings are sequences. - The value of the mapping with the key
languages
is also a mapping.
YAML file size
SnakeYAML 1.32 restricts the size of YAML files to a maximum of approximately 3 MB to prevent potential issues with untrusted sources. Be aware that this might break existing setups if they use YAML files larger than this accepted limit. We recommend splitting large bootstrap files or using XML bootstrap files as a workaround.
Further resources about YAML
YAML specification and documentation
- yaml.org (The Official YAML Web Site)
- YAML Specification Index
- Index of YAML terms (YAML 1.2)
- A reference card (YAML 1.1)
- snakeyaml (the YAML parser used by Magnolia)
- en.wikipedia.org/wiki/YAML
- docs.ansible.com/YAMLSyntax.html
Editors supporting YAML syntax
- Atom (YAML related packages)
- Brackets
- Eclipse (with plugin)
- Emacs (with plugin)
- IntelliJ (with plugin)
- Light Table
- Sublime text
- Vim (with plugin by YAML's original author)
Online YAML tools
- Parsers and linters
- Converters