Site engine
Contents
The Site engine enables development and delivery of content driven web apps AKA sites.
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/<project>/<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}/_templatesfolder) 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.
