HST Configuration Model Introduction

When developing websites with BloomReach Experience Manager's delivery tier (a.k.a. "HST") it helps a lot to understand the backing configuration model. For a first acquaintance with the model without the need to understand it, you are encouraged to follow the Build a Website tutorial.

Developing a website with the HST in general can be decomposed into four main categories:

Content stored in the Hippo Repository / HST Content Beans ( Model)

Java classes for HST Components ( Controller)

Rendering templates like JSP or Freemarker ( View)

HST configuration model: configuration (stored in Hippo Repository) for the Hierarchical MVC glue of points 1, 2 and 3 above and the configuration for the request matching part of the HST framework.

For a proper understanding of the request matching and request processing concepts, it is important to understand the HST configuration model. This chapter will dissect and zoom in on the different parts of the HST configuration model.

Where is the HST configuration stored?

The HST reads its configuration model from the content repository. The model is (by default) stored below the node /hst:hst.

How and when is the model loaded?

When a request hits an HST site application, the HST will try to match that request against its model. When there is no model present, the HST will load the HST configuration from the repository and builds an in-memory model of that configuration. Whenever the configuration in the repository changes, the HST will reload its model. Since the model can be very large (100.000+ configuration nodes), covering configuration of thousands of sites, the model loading is lazy and reuses previously loaded configuration parts that did not change. Apart from very efficient loading, requests can be served with stale model support to avoid hiccups. A model instance itself can best be seen as an append-only model: everything that has been loaded is immutable.

HST main configuration nodes

Right after the BloomReach Experience Manager application has started as described in the Getting Started Trail, the repository gets bootstrapped with some initial HST configuration nodes. Assuming project name example, then logging in at http://localhost:8080/cms/console, you can see below the node /hst:hst in the repository the following main configuration nodes:

hst:sitemap : Contains a composite tree of sitemap items that are used to match the request path (after the matched mount) against. A sitemap item points in general (unless for example REST or other kind of rendering) to an hst:component node, which is in most cases a child node of hst:pages. A sitemap item generally contains a reference to which content (document) is mapped to the current request.

hst:workspace : Contains all configuration nodes for the site example that can be modified at runtime by a webmaster through the Channel Manager. For example changes through the channel manager by a webmaster never end up directly below /hst:hst/hst:configuration/example/hst:sitemap but always below /hst:hst/hst:configuration/example/hst:workspace/hst:sitemap. This way we can assure that all changes made by webmasters can be kept apart from changes made by developers (through for example bootstrap configuration) as the changes from developers typically do end up below /hst:hst/hst:configuration/example/hst:sitemap instead.

hst:channel : The channel name that is visible in the CMS channel manager plus channel configuration parameters. The hst:channel node can also be a sibling of the hst:workspace node: In this case, the channel settings will be read-only in the Channel Manager.