Docs Developer Site
Enonic XP
arrow-down
  1. Manifesto
    1. Projects
    2. Build System
    1. Globals
    2. HTTP
    3. Controllers
    4. Filters
    5. Events
    6. Websocket
    7. Error handler
    8. ID provider
    9. Tasks
    10. Localization
    11. Java bridge
      1. Webapp Engine
        1. Image service
        2. Component service
      3. Admin Engine
      4. Asset service
      5. HTTP service
      6. IDprovider service
    2. Task engine
    3. Management Endpoint
    4. Statistics Endpoint
    1. NoQL syntax
    2. System properties
    3. Index configuration
    4. Aggregations
    5. Highlighting
    6. Branches
  6. IAM
    1. Widgets
    1. Schema System
    2. Mixins
    3. Input Types
    4. Content Types
    5. X-data
    6. Macros
    7. Sites
    8. Page Components
    9. Contributions
    10. Mappings
    11. Response Processors
    1. Strategies
    2. Distributions
    3. Vhosts
    4. Configuration
    5. Data management
    1. Admin API
    2. Authentication API
    3. Cluster API
    4. Common API
    5. Content API
    6. Context API
    7. Event API
    8. I18N API
    9. IO API
    10. Mail API
    11. Node API
    12. Portal API
    13. Repo API
    14. Tasks API
    15. Value API
    16. Websocket API
    1. Upgrade Notes
    2. Upgrading Apps
Enonic XP Runtime HTTP engines Site Engine

Site engine

Contents

Site engine

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-techinical 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:

Site rendering 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 it’s controller + config (optionally via page template). If no controller is found, the return code is set to 404.

Page renderer

Based on the controller in the previous step is executed, producing output - potentially including component placeholders

Component renderer

For text/html responses, any compontent placeholders in the response body are processed. Each compontent’s controller is executed and the output replaces the compontent placeholder in the response body. Layouts compontents 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 _/compontent/ url pattern trigger direct access to the component service. Enabling direct HTTP request processing on a single compontent. This is effectively a subset of the site engine itself.

Contents