HST Workspace Configuration - BloomReach Experience - Open Source CMS

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

04-07-2016

HST Workspace Configuration

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

+ hst:hst
  + hst:configurations
      + example
         + hst:abstractpage
         + hst:catalog
         + hst:components
         + hst:pages
         + hst:prototypepages
         + hst:sitemap
         + hst:templates
         + hst:workspace

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, for example by using the JCR diff and patch feature described at  HST configuration updates. 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 others 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.

Note that the HST Configuration Editor (through the little cogwheel in the right top) still writes changes to non workspace configuration nodes. This is because the HST Configuration Editor is in fact more a developer kind of tool. In production we hence recommend to switch off the HST Configuration Editor to avoid changes being made in non workspace configuration nodes.

Recommended: Switch off the HST Configurtion Editor in production, see part 'Recommended' at page Channel Manager

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:sitemenus
    + hst:pages
    + hst:sitemap
    + hst:containers 

Apart from the  hst:containers node, which is explained a Containers configuration, the configuration nodes below the workspace are similar to the regular  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.

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}
Workspace inheritance as shown above is only supported since CMS 10.1.0 and onwards

See Configuration Inheritance for more documentation about inheritance of entire configurations and of workspace inheritance.

 

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?