Experience Page Layouts Configuration

Introduction

Experience Pages are self-contained pages combining content and page layout, adding the option of a page-driven approach to Bloomreach Experience Manager. An Experience Page Document is created by a CMS user and has an embedded page configuration that is an instance of an Experience Page Layout. Experience Page Layouts are configured by developers within an implementation project's HST configuration.

Configuration

Below a node of type hst:configuration, an optional node hst:xpages can contain hst:xpage nodes defining Experience Page Layouts. For example:

+ hst:myproject 
  + hst:configurations
    + myproject
      + hst:xpages             [hst:xpages]
        + one-column-xpage     [hst:xpage]
          - hst:referencecomponent = hst:abstractpages/base
          + main               [hst:containercomponent]
            - hippo:identifier = 4d1776f0-faa8-4913-a94f-89d5e87bfce3

The hst:xpage node type extends from hst:component, the node type used for regular pages configured below hst:pages. It has the exact same configuration options as an hst:component with the addition of:

1. hst:pageref: A property that is used only in user-created Experience Page Documents containing an hst:xpage node and should never be set by developers and never be present on hst:xpage nodes within the HST configuration.

2. hst:label: the name of the Experience Page Layout to choose from when creating a new Experience Page Document.

Identifiable Containers

Nodes of type hst:containercomponent have mixin type hippo:identifiable. Any node with the mixin hippo:identifiable behaves as follows:

1. When newly created, the node automatically gets a property hippo:identifier with as value a newly created random UUID

2. When the property gets removed, it is not added again.

3. When a node of type hippo:identifier gets copied and the source does not have a hippo:identifier, then hippo:identifier property is added with a newly created random uuid as value. If the source did have the hippo:identifier property, then it is copied as-is, thus the target gets the same hippo:identifier property with the same value

The purpose of the hippo:identifier property is to have a stable identifier across nodes if neither the jcr:uuid nor the jcr:path is suitable for it.

HST configuration nodes of type hst:containercomponent have the mixin type hippo:identifiable such that container items by default always get the hippo:identifier property. Developers should never modify the value of a hippo:identifier and don't copy them in YAML files across different container nodes or xpages. If a bootstrapped hst:containercomponent from a YAML file does not have a hippo:identifier, the hippo:identifier property gets created when the container node gets created (bootstrapped).

In the case of Experience Pages, the hippo:identifier is used to create a reference between the Experience Page Layout container and the Experience Page Document container.

Containers with Default Container Items

It is possible for a Experience Page Layout to have a configuration with containers already having one or more container items added by default. In this case, the containers' container items are copied into the Experience Page Document container and are thus handled as prototypes.

Inheritance

Like hst:pages, hst:xpages can be inherited from other HST configurations.

For example, in the setup below:

+ hst:myproject 
  + hst:configurations
    + common
      + hst:xpages             [hst:xpages]
        + common-xpage     [hst:xpage]hst:configurations
    + myproject
      - hst:inheritsfrom = ../common
      + hst:xpages             [hst:xpages]
        + one-column-xpage     [hst:xpage]

The myproject configuration inherits the xpage layout common-xpage.

However, the hst:xpages node is not supported below the hst:workspace (as opposed to hst:pages). The reason is that hst:xpages layout configuration is fully controlled by developers.

Note that the -preview configuration or branches of myproject do not get a copy of the hst:xpages node since only the hst:workspace is copied: those HST configurations will inherit the hst:xpages from the primary (core) live configuration which is different since it is for the same channel id.

For example, in case of:

+ hst:myproject 
  + hst:configurations
    + myproject
      + hst:workspace
      + hst:xpages             [hst:xpages]
        + one-column-xpage     [hst:xpage]
    + myproject-preview
      - hst:inheritsfrom = ../myproject
      + hst:workspace
    + myproject-v8UfB:
      - hst:inheritsfrom = ../myproject
      - hst:branchid: v8UfB
      - hst:branchof: myproject
      + hst:upstream
      + hst:workspace
    + myproject-v8UfB-preview:
      - hst:inheritsfrom = ../myproject-v8UfB
      - hst:branchid: v8UfB
      - hst:branchof: myproject
      + hst:workspace

then myproject-preview, myproject-v8UfB and myproject-v8UfB-preview will all inherit the hst:xpages from the live primary myproject.  

Note that this means that whenever a different channel needs the same hst:xpages layouts, you need to either duplicate them or store them under a common HST configuration from which the channels inherit (recommended).