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:

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. 

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]

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.