Categorization

As described in Configuration vs. Content, the Configuration Model also defines how Bloomreach Experience Manager should handle repository data which is not part of the Configuration Model. For this purpose, repository data is categorized into three categories:

1. Configuration (config)
   Configuration is the default category. This means that if you define a new configuration node, all its properties and child nodes will be categorized as configuration, unless explicitly specified otherwise.
   If the Configuration Model is force-applied to the repository, data of this category, which is not present in the Configuration Model is removed from the repository. Direct child nodes of the root node are an exception to this rule: by default, they are categorized as system.

2. Content (content)
   If the Configuration Model is force-applied to the repository, data of this category is left untouched as long as the node where it attaches to the Configuration Model (base-node in the example below) is not deleted. This piece of repository data can be managed using content Sources and content actions. The content category can only be assigned to nodes and not to properties.

3. System (system)
   If the Configuration Model is force-applied to the repository, data of this category is left untouched as long as the node where it attaches to the Configuration Model (base-node in the example below) is not deleted.

In order to categorize specific properties of child nodes of a node as content or system, you can explicitly specify that category in your configuration Source file:

 /path/to/base-node:
   system-property:
     .meta:category: system
   /content-base-node:
     .meta:category: content

A category specification does not actually create the property or node (there are no values to assign to it), it only declares its category, should the property or node exist in the repository.

Above example defines that the property system-property of the base node should be treated as system data, and the node content-base-node, along with its properties and child nodes, should be treated as content, while the base-node is treated as configuration. Note that:

• Valid values for nodes are: config, content and system

• Valid values for properties are: config and system; content is not supported as it is not possible to load a single property through a content definition

• Specifying .meta:category for jcr:primaryType and jcr:mixinTypes is not supported

It is possible to override the category of upstream nodes or properties. When overriding a node or property from config to content or system, it is deleted from the configuration model, and only its category is retained. When overriding a node or property from content or system to configuration, it is possible to specify additional properties, nodes and values which will then also be considered configuration.

In order to categorize any child node of a base configuration node, which is not part of the Configuration Model, use the following meta-definition:

 /path/to/base-node:
   .meta:residual-child-node-category: content
   /configuration-child:
     jcr:primaryType: node:type

Above example defines that all child nodes of base-node found in the repository, other than child node configuration-child are categorized as content. Like this, you don’t need to know the exact names of potential content child nodes upfront.

There is no equivalent to the residual-child-node-category for properties; properties of a category other than configuration must all be categorized explicitly.