Containers configuration

The Workspace configuration page explained that the following configuration nodes can be placed below the hst:workspace node:

+ hst:workspace
    + hst:sitemenus
    + hst:pages
    + hst:sitemap
    + hst:containers

On the Workspace configuration page, we already explained hst:sitemenus, hst:pages and hst:sitemap. This page explains the hst:containers section.

hst:containers

Through the Channel Editor a webmaster can modify certain configurable regions of a web page. These regions are called containers. Containers are only modifiable when they are stored in the hst:workspace. Or more explicitly, when they are configured either 

1. below hst:workspace/hst:pages or
2. below hst:workspace/hst:containers.

This is to enforce that runtime production changes through the Channel Editor do not end up outside the hst:workspace.

Containers configured outside the workspace are not editable. When a non-workspace page (maintained by developer / bootstrap content) needs to have editable regions, then that page needs to reference containers below  hst:workspace/hst:containers. An example configuration (relevant parts) making use of hst:workspace/hst:containers setup is as follows:

+ example
   + hst:pages
   |  + home                                     [hst:component]
   |     + main                                  [hst:component]
   |        + content                            [hst:component]
   |           + container                       [hst:containercomponentreference]
   |              - hst:referencecomponent = home/container
   + hst:workspace
      + hst:containers                           [hst:containercomponentfolder]
         + home                                  [hst:containercomponentfolder]
            + container                          [hst:containercomponent]
               + list                            [hst:containeritemcomponent]

The configuration above has two new node types:

1. hst:containercomponentreference: this nodetype has one mandatory property hst:referencecomponent. The property must contain a relative path to a node of type hst:containercomponent. The hst:containercomponent node is located in the hst:workspace/hst:containers node.

   If the hst:containercomponent is not present, or the path in hst:referencecomponent is incorrect, the HST does not load the hst:containercomponentreference  into it’s model, i.e. it is entirely skipped.

   Important!

   The HST model uses the node name of hst:containercomponentreference  and not the node name of the hst:containercomponent. For example, if the name of the hst:containercomponentreference node is  mycontainer but the hst:referencecomponent refers to a hst:containercomponent with name yourcontainer, then the HST model knows the component as mycontainer. So, you need to use mycontainer in the hst:include tag:

   <hst:include ref="mycontainer" />

    

   + example
      + hst:pages
      |  + home                                     [hst:component]
      |     + main                                  [hst:component]
      |        + content                            [hst:component]
      |           + mycontainer                     [hst:containercomponentreference]
      |              - hst:referencecomponent = home/yourcontainer
      + hst:workspace
         + hst:containers                           [hst:containercomponentfolder]
            + home                                  [hst:containercomponentfolder]
               + yourcontainer                      [hst:containercomponent]
                  + list                            [hst:containeritemcomponent]

2. hst:containercomponentfolder: this is only a placeholder node that can contain another hst:containercomponentfolder or a hst:containercomponent that can be referenced.

The CNDs for the two new node types are: 

[hst:containercomponentreference] > nt:base orderable
- hst:referencecomponent (string) mandatory

[hst:containercomponentfolder] > nt:base orderable
+ * (hst:containercomponentfolder)
+ * (hst:containercomponent)

Pages in the hst:workspace technically can also use the mechanism to store their containers below hst:workspace/hst:containers, however it is most likely easier to maintain if the containers for hst:workspace pages are just stored below the page directly, for example:

+ example
   + hst:workspace
      + hst:pages
        + home                                     [hst:component]
          + main                                   [hst:component]
            + content                              [hst:component]
              + container                          [hst:containercomponent]
                 + list                            [hst:containeritemcomponent]

Summary  

Only containers stored in the hst:workspace can be modified through the Channel Editor. Modifiable containers can be explicitly stored below hst:workspace/hst:pages or below hst:workspace/hst:containers, in which case they can be referenced by non-workspace pages.