HST Workspace Configuration - BloomReach Experience - Open Source CMS

This article covers a Hippo CMS version 12. There's an updated version available that covers our most recent release.

20-06-2018

HST Workspace Configuration

On the HST configuration model introduction page the following example was presented:

/hst:hst
  /hst:configurations
    /example
      /hst:abstractpage
      /hst:catalog
      /hst:components
      /hst:pages
      /hst:prototypepages
      /hst:sitemap
      /hst:templates
      /hst:workspace
        /hst:channel
          /hst:channelinfo

On the previous pages we have described all elements above except  hst:prototypepages and  hst:workspace. This page is about hst:workspace. The hst:workspace was introduced to support a cleaner separation between

  1. Changes as a result of developers creating (in a local development environment) new features that require HST configuration updates in a production environment
  2. Changes in a production environment made in the HST configuration as a result of webmasters working in the Channel Manager.

Prior to the hst:workspace, changes to the configuration made by webmaster in a production environment would end up for example directly below /hst:hst/hst:configuration/example/hst:pages.

At the same time developers could have made changes to  hst:pages as well, that need to be merged into production. However, this is delicate and requires alignment between webmasters, developers and infrastructure personell carrying out new deployments. How much easier would it be if webmasters and developers wouldn't have to think about each other's swim lane so much?

The hst:workspace 

Exactly for this reason, the HST has introduced the concept of the hst:workspace:

The hst:workspace is where changes made by webmasters in the Channel Manager are stored

With the introduction of this simple practice, we achieved that changes made in the Channel Manager in a production environment are stored below  /hst:hst/hst:configuration/example/hst:workspace.

In general, a developer locally never makes (bootstrap) changes below the hst:workspace. This means the developers' changes can in general always override the entire configuration below /hst:hst/hst:configurations/example during a new deployment.

hst:workspace nodes

The supported workspace configuration nodes are:

/hst:workspace:
  /hst:containers:
  /hst:sitemenus:
  /hst:abstractpages:
  /hst:pages:
  /hst:components:
  /hst:sitemap:
  /hst:channel:

Apart from the  hst:containers node, which is explained a Containers configuration, the configuration nodes below the workspace are similar to the non-workspace  hst:pages, hst:sitemap and hst:sitemenus nodes. In the final HST model, the configuration nodes between workspace and non-workspace are merged into a single sitemap, pages and sitemenus section. 

Since CMS 12.0.0, the hst:workspace allows hst:abstractpages, hst:components, hst:templates and hst:channel. The hst:channel is allowed since we moved the channels from /hst:hst/hst:channels into the hst configuration nodes (where they should have been in the first place). The other added nodetypes are required because when cross-channel-page-copy is supported, for example templates might be missing in the target configuration and thus need to be copied as well....but the -preview configuration only contains the hst:workspace since CMS 12.0.0 : Hence, everything needs to be copied to the hst:workspace and as a result, the hst:workspace must support also abstractpages, components and templates.

Workspace and non-Workspace merging rules

The HST does a coarse-grained merge of the hst:workspace configuration and the non workspace developer bootstrap configuration. The merge is coarse-grained as in that a node below one of the workspace main nodes ( hst:sitemenus, hst:pages and hst:sitemap) is only included in the HST configuration if it does not already exist at the developer bootstrapped configuration. Thus for example, if we have

/hst:hst:
  /hst:configurations:
    /example:
      /hst:sitemenus:
        /footer:
          /contact:
      /hst:workspace:
        /hst:sitemenus:
          /footer:
            /address:

then the workspace footer  hst:hst/hst:configurations/example/hst:workspace/hst:sitemenus/footer is completely skipped as it already exists at  hst:hst/hst:configurations/example/hst:sitemenus/footer.

In the end result, there is thus no address in the merged configuration.

If we have the following example:

/hst:hst:
  /hst:configurations:
    /example:
      /hst:sitemenus:
        /footer:
          /contact:
      /hst:workspace:
        /hst:sitemenus:
          /main:
            /home:
            /about:

Then because the workspace hst:sitemenus has a different child node ( main instead of footer), the final merged configuration result in:

/hst:sitemenus:
  /footer:
    /contact:
  /main:
    /home:
    /about:

The same merging as above explained holds for hst:pages and hst:sitemap.

Inherited configuration workspace nodes are by default ignored

The HST configuration can support inheritance between entire configurations, for example

/hst:hst:
  /hst:configurations:
    /common:
    /example:
      hst:inheritsfrom: [../common]

 If the  common configuration contains a hst:workspace configuration, this configuration is by default not inherited for the example configuration. In other words:

By default, workspace configuration is local to a configuration

If you want to inherit workspace configuration as well, you need to explicitly add this inheritance :

/hst:hst:
  /hst:configurations:
    /common:
    /example:
      hst:inheritsfrom: [../common, ../common/hst:workspace]
See Configuration Inheritance for more documentation about inheritance of entire configurations and of workspace inheritance.

Workspace inheritance in case of cascading inheritance

/hst:hst:
  /hst:configurations:
    /common:
    /example:
      hst:inheritsfrom: [../common, ../common/hst:workspace]
      /hst:workspace:
    /subexample:
      hst:inheritsfrom: [../example]

In the above configuration, subexample will inherit the workspace configuration from common but not the workspace from example: The common workspace is inherited via cascading inheritance, but the example workspace is not explicitly configured to inherit from and thus skipped.

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?