Site engine

Sites vs webapps

Sites are essentially content driven webapps. This means that URLs and the content within the application can be controlled by non-technical editors. In XP this boils down to a mapping between content (from the Content API) and a controller. Unlike webapps, sites do not have a default controller.

Another important difference from webapps is that sites may be powered by multiple apps. The apps may even collaborate on processing and responding to a single request. Similar to webapps, sites also enable developers to take control over URL patterns when needed, through filters and mappings (as described below).

For more details on building site specific applications, check out the CMS documentation.

Endpoint

The site engine is responsible for processing of requests on the endpoint :8080/site/<project>/<branch>/*. <project> and <branch> refer to CMS specific projects and branches, for instance :8080/site/default/draft

Request pipeline

The site pipeline is executed as a subset of the common pipeline:

This section describes the standard pipeline involved in processing a page request i.e. :8080/site/<repo>/<branch>/<path-to-page>.

Mappings: Uses path and content based mappings from site descriptor to trigger filters and controllers
Page resolver: Looks up content in path, and resolves its controller + config (optionally via page template).

For two content types Page resolver does not resolve any controller. - For base:shortcut the referenced content path is returned with status code 307 Temporary Redirect. - For portal:fragment controller is not applicable. A fragment is rendered directly.

For the rest of content types controllers are considered in the following order:

Controller that is set directly on content.
Controller that is set on a page template for content. If set page template is unavailable (i.e. deleted), Page resolver considers it as if page template was not set.
Controller that is set on the first found page template (in {site}/_templates folder) that supports content’s content type.

If no controller is found, response status code is set to 404 Not Found.

In inline rendering mode response status code is set to 418 instead of 404, so Content Studio can switch to alternative rendering. In edit rendering mode status code is 200 instead of 404 to allow Content Studio to render in-place Controller selector.

Page renderer

Resolves controller and optional configuration (could also come from page template).

If controller is missing, returns 404 (Not found)
If controller exists, executes it and returns 200 (OK) by default. Output may potentially include component placeholders

Component renderer

For text/html responses, any component placeholders in the response body are processed. Each component’s controller is executed and the output replaces the component placeholder in the response body. Layouts components may leave new placeholders, as such, this step will be repeated until no placeholders remain to be processed.

Response processors

For text/html responses, any response processors defined in the site descriptor will be executed. Processors may manipulate the result, for instance by adding pageContributions

Contributions filter

For text/html responses, any pageContributions in the response object will now be merged into the response body.

Response filters

Any filters registered through a mapping may now execute their final processing before the response is returned from the pipeline.

Image service

Requests for the _/image/ url pattern activate the image service, which will process and return images on demand

Component service

Requests for the _/component/ url pattern trigger direct access to the component service, enabling direct HTTP request processing on a single component. This is effectively a subset of the site engine itself.