This article covers a Bloomreach Experience Manager version 12. There's an updated version available that covers our most recent release.

HST Server Side Includes Support

Introduction

HST provides basic support for generating  SSI (Server Side Includes) statements, so that external SSI processors like Apache, Nginx, LightHttpd and IIS can include certain components in an asynchronous way.

 

Server Side Includes (SSI) is a simple interpreted server-side scripting language used almost exclusively for the Web.

You can configure HST Components to be served as SSI markup instead of fully-rendered HTML markups. In this case, the SSI markup in the response will be processed by the external SSI Processor to replace the SSI markup with the full retrieved HTML markup in the final phase.

SSI has a simple syntax:

<!--#directive parameter=value parameter=value --> 

Directives are placed in HTML comments so that if SSI is not enabled, users will not see the SSI directives on the page, unless they look at its source. 

 

How to Make an HST Components Render SSI Markup?

An HST Page is constructed from a tree of HST Components, managed in Hippo Repository.

First of all, you should mark an HST Component as asynchronous by setting the  hst:async property. If you set an HST Component as asynchronous, the HST Component and its descendants will be rendered asynchronously.

hst:async: true 

Above configuration by default results in an asynchronously rendered HST Component window via client-side AJAX script calls.

See Asynchronous HST Components and Containers for details on asynchronous HST Components.

Now, asynchronous HST Components can also be rendered/aggregated on the server side by an external SSI Processor.

If you want to change the default AJAX asynchronous rendering behavior to SSI processing, you should add the following property:

hst:asyncmode: ssi 

The default value of hst:asyncmode is ajax.

If an HST Component is configured as asynchronous with an  hst:asyncmode of ssi, the rendered markup of the HST Component window will be SSI markup in the first phase like the following example:

<!--#include virtual="/news?_hn:type=component-rendering&amp;_hn:ref=r1_r2" --> 

The SSI Include source is an HST Component Rendering URL, which invokes a specific HST Component window (having ' r1_r2' namespace) rendering instead of rendering the whole page.

So, HST's page response includes all HTML markup for all descendant HST Component windows except for SSI-based asynchronous HST Component window. The markup of the asynchronous HST Component windows is replaced by SSI markup as in above example.

Now, the whole page can be processed by external SSI processors such as Nginx or Apache httpd. The external SSI processor will invoke the SSI Include URL (e.g,  /news?_hn:type=component-rendering&amp;_hn:ref=r1_r2) and replace the SSI markup by the retrieved HTML markup to serve the final page output to the client.

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?