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

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. Bloomreach Experience Manager does not aim to solve every problem but rather provides an extensible platform that enables you to adapt it to your needs.

Extension Pattern

Bloomreach Experience Manager’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.

Extension Points

MVC Components

Our 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.

 

HippoBean interface

HMVC model extension using the HippoBean interface.

 

HstComponent interface

HMVC controller standard components extension.

 

Request Handling

Both the matching and the processing phases of the request handling by Bloomreach Experience Manager’s deliver tier are extensible.

In the matching phase URLs are matched to a so-called sitemap item, which defines the page component configuration and content to render. This behavior 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.

 

SiteMapItemHandler interface

Request matching extension using the HstSiteMapItemHandler interface.

 

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.

 

OrderableValve interface

Request processing extension using the OrderableValve interface.

 

RESTful Services

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

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?