Sometimes the configuration value being exported is not static and can depend on the data being exported itself. Two areas where this occurs are with image styles where the attributes for the effects depend on the type of effect, and Views where the values for plugins depend on the plugin type. Variables from the export can be combined to form the data type for the element. These variables are enclosed in [] brackets and follow one of the following rules:
- [value] where value is an attribute of current element; for example, views.field.[table]-[field] would construct the type based on the attributes of table and field found in the mapping
- [%key] refers to the key of the current element
- [%parent] refers to the parent of the current element and is usually combined with an attribute; for example, views.display[%parent.display_plugin] would construct the type based on the display_plugin attribute of the current element's parent
A comprehensive example can be seen in the initial image styles; for example, in image.style.large.yml in core/modules/image/config/install you have:
langcode: en
status: true
dependencies: { }
name: large
label: 'Large (480×480)'
effects:
ddd73aa7-4bd6-4c85-b600-bdf2b1628d1d:
uuid: ddd73aa7-4bd6-4c85-b600-bdf2b1628d1d
id: image_scale
weight: 0
data:
width: 480
height: 480
upscale: false
This is governed by the schema defined in image.schema.yml:
image.style.*:
type: config_entity
label: 'Image style'
mapping:
name:
type: string
label:
type: label
label: 'Label'
effects:
type: sequence
sequence:
type: mapping
mapping:
id:
type: string
data:
type: image.effect.[%parent.id]
weight:
type: integer
uuid:
type: string
You see that effects are a sequence, where the data attribute type depends on the value of the id attribute of the parent. So, when parsing the large image style effects data, it goes up one level to the UUID and then the id value, which is image_scale, and uses the type image.effect.image_scale.