// RADICALLY OPEN

Extensibility|

 

Content delivery is a dynamic space. You want a platform that can accommodate the unique requirements of any CMS implementation. Therefore extensibility is a key quality attribute of any content delivery architecture. Hippo CMS does not aim to solve every problem but rather provides an extensible platform that enables you to adapt it to your needs.

 

 

Banner image

Hippo CMS’s delivery tier has extension points designed into all relevant areas of its architecture. All major components have interfaces, abstract base classes and various standard implementations which are extensible. Following the inversion of control design, they are substitutable either through Spring configuration or even on-the-fly through configuration stored in the content repository.

  • MVC Components

    The Hippo CMS delivery tier uses the Hierarchical Model-View-Controller pattern for page rendering. Both models - called 'content beans' - and controllers - called 'components' - are interface-based and are extensible and substitutable. Many use cases can be implemented by using or extending one of the many standard components provided. If needed they can be written from scratch.

    Views can be rendered by different templating engines, with Freemarker and JSP implementations provided out-of-the-box. A standard tag library is provided and can be extended as well.

     

    HMVC model extension using the HippoBean interface.

     

    HMVC controller standard components extension.

     

     

  • The Matching Phase

    In the matching phase, URLs are matched to a so-called sitemap item, which defines the page component configuration and content to render. This behaviour can be extended using sitemap item handlers to e.g. modify request attributes, add response headers or cookies, return a different sitemap item or even delegate the request to a different servlet.

     

    Request matching extension using the HstSiteMapItemHandler interface.

     

     

  • The Processing Phase

    The processing phase is performed using a processing pipeline consisting of valves. Each individual valve has exactly one responsibility, e.g. security, localization, content retrieval, component rendering, page aggregation and caching. Standard pipelines for HMVC-based web page rendering and for JAX-RS based RESTful services are provided out-of-the-box. Pipelines use inversion of control and are assembled through Spring configuration. The request processing can be extended by inserting custom valves at any point in the pipeline.

     

    Request processing extension using the OrderableValve interface.

The delivery tier’s support for JAX-RS provides extensibility through custom REST endpoints. This opens up many possibilities including complex content integrations and Content-as-a-Service (CaaS) scenarios.