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:

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.

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:

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.