Storefront

This chapter gives an overview of all basic concepts used in the CMS. A shop storefront is broken down into the essential parts as seen by the CMS.

The diagram above shows a simplified version of a shop storefront structure with the constituent elements. The elements are partitioned in the way the storefront is viewed and managed by the CMS. The structure itself, i.e., the relations between the nodes or pages, is not part of the CMS. This structure is rather implicitly encoded in the viewing pipelines and ISML templates coming with the storefront application. The CMS comes into play when the content is to be displayed at the nodes of the storefront structure in a manageable and flexible way. This display is dependent on certain criteria such as time, the user visiting the storefront, active promotions or A/B tests, and so on.

Pages

The content itself that is to be brought to and displayed in the storefront by means of the CMS can be roughly divided into two groups:

1. Content Pages: Content in its pure classical sense, such as simple text or media objects. Typical examples are terms and conditions, imprint, news article or FAQ. Storefront pages presenting such content are called "Content Pages".
2. Dynamic Pages: Catalogs and products within the catalogs make up an essential part of the storefront as seen by a consumer. These data are very flexible in that catalogs or categories and products within them may go online or offline, or they may be added or deleted over time. Some products or categories may be of a certain type and therefore need a display different from the usual one. All pages presenting these data together with the hierarchical and dynamic data structure are hence called "Dynamic Pages".
   So far, there are only dynamic pages for the browsing of catalogs, categories and products which are logically named "Category Pages" and "Product Pages".
   In addition, it is also possible to display other business objects in the storefront via the CMS (as described in the Cookbook - CMS (7.4 - 7.4 CI)).

Apart from the content in content pages, a storefront has to provide a lot of functionality dealing with, e.g., basket handling, order processing or product search. The pages presenting these functional blocks to the consumer in the storefront are called "Functional Pages".

Intra-Page Artifacts: Page Variants, Components, and Configuration Parameters

All types of pages mentioned in the last section may be implemented in the storefront by using the CMS. Since pages may alter their appearance according to certain criteria, the CMS considers them as having an inner structure that consists of the entities embodying several appearances. Such an entity is then called "Page Variant". The following diagram outlines this concept by showing a page that changes its appearance each weekday:

So, in terms of a CMS, a page is an entity with its own identity and page variants (being entities themselves) as its constituent elements.

A page variant implements the appearance of a page, but most likely has an inner structure itself. A page variant can be decomposed into its inner parts or vice versa put together from smaller parts which in turn may also be built up from smaller parts and so on. In other words: the structure of pages simply follows the composite pattern with page variants always being root composites. These root composites are not part of other composites, and all the other units are composites or leafs.
In the CMS, the normal composites are called "Components" and the leafs "Configuration Parameters". Configuration parameters are single objects without any child objects; they usually represent the actual content in the CMS, such as text, images, links and so on.

The following diagram compares the common composite pattern with its application to the CMS, i.e., page variants, components, and configuration parameters:
There is a slight derivation to the original pattern in the CMS. First, what is called "component" in the composite pattern is named "composable" here. Additionally, there are two composites instead of one: component and page variant. Only one of them may be part of another composite, namely the component. A page variant cannot be part of another page variant or component since a page variant always represents a whole page in a browser or other output device.

Content Aspects

The CMS or content may be viewed from various perspectives or according to different aspects and then divided into several concepts, layers or artifacts. The last chapter has already given an overview of the CMS from a back office user's perspective. This chapter tries to labor on further perspectives to line out all the common conceptual patterns and layers used throughout the whole CMS.

Plug In Content Elements Somewhere Else: Content Entry Points

One content aspect deals with the question of how to plug in certain content units somewhere else, be it other content elements or non-content elements such as pipelines or plain ISML templates. The general concept covering this aspect in the CMS is called "content entry point".
One type of content entry point has already been introduced, namely the "page". One of its tasks is to link page variants directly into the storefront structure at defined nodes. This can be done by placing a page directly at the end of a viewing pipeline (as already mentioned, the storefront structure is mainly encoded in viewing pipelines). When the pipeline is executed, the page will select the proper page variant which will then be rendered as the final result of the pipeline in the storefront.

The concept of content entry points implies another kind of content elements, the ones to be plugged in somewhere else and as such must embody real content that is rendered in the storefront. The above-mentioned page variants are one type of these elements; the others are components and configuration parameters.

Content entry points must not only be considered as simple connecting links of content to, e.g., the storefront. Rather, they are like an entity with separate identities. Therefore, content entry points can be referenced and used at several places and hold a collection of page variants or components. Content entry points can also apply a certain set of business rules on the collection when one element of the collection is to be selected for rendering. The default set of business rules allows for

• prioritization,
• the application of time constraints,
• personalization,
• and the application of A/B test as well as testing whether content is somehow part of a promotion or campaign.
  Some types of content entry points even provide the possibility to apply type rules to their components or page variants.

The diagram shows an overview of all types of content entry points which will be explained in up-coming sections. Placeholders are only mentioned here for the sake of completeness and will be described in a separate document: Concept - Content Templates. Placeholders require familiarity with a lot of concepts in advance, hence will not be explained in this document; placehholders embody an advanced concept of content composition.

Getting Content Into the Storefront: Page and Component Entry Points

Page entry points and component entry points are the means to link managed content to the storefront. Storefront here means all the viewing pipelines and ISML templates being part of the storefront application.

Page entry points may be imagined as a replacement for the interaction nodes in pipelines; they take over the task of the interaction nodes which is to render a particular ISML template. Page entry points, in contrast to interaction nodes, render page variants instead of plain ISML templates. As already mentioned, a page entry point may have more than one page variant assigned to it. The page variant that is chosen when a page entry point is to be rendered depends on how it is configured and what the current execution environment is, i.e. the data in the pipeline dictionary, current request and session. Additionally, as page entry points are meant to embody pages in the classical sense, i.e. as seen by storefront users, they will render only one page variant at a time which will then completely fill the output device, be it a browser or maybe a mobile device.

Component entry points may be regarded as a replacement for ISML includes or modules. They come in quite handy if parts of a storefront are realized in the conventional way, i.e., not using the CMS for the implementation of complete pages. One wants to have certain spots within a page that are manageable by the CMS. Typical examples are page headers or mini carts. The content elements a component entry point brings to the storefront are components, but, contrary to page entry points, component entry points can render more than one component at a time. The configuration will be explained later on.

From a runtime perspective, content entry points are eventually realized by POs and as such are passive objects, i.e. they cannot render by themselves. Therefore, the CMS comes along with facilities to embed page entry points and component entry points in the storefront; the former will be bound to the storefront by a special pipeline, ViewPage-Start, and the latter by a particular ISML tag, ISContentInclude. Both have to be configured with the ID of the content entry point to be rendered. This can be done either literally or dynamically by using an ISML expression.

Content Composition: Slots

Almost all page variants most likely have an inner content structure comprised of components which in turn may consist of further components. The means to allow for this kind of content composition are slots. Slots are spots or areas in page variants and components where other components can be plugged in. It is possible to fill one slot with more than one component. Which ones and how many of them will be shown in the storefront is decided at rendering time and is steered by certain facilities that will be explained later on.

The left part in the depiction above shows a page variant meant to present categories together with their products in the storefront. It has three areas:

• a header area: to accommodate common information such as user account data, the mini cart, or the company logo
• a footer area: for terms and conditions, the imprint, contact details and so on
• a main area: for catalog browsing and product listing

Technically, each of these areas is represented by a slot which then holds further components. The header slot is filled with a header component, the footer slot with a footer component, and the slot representing the main area with a product browsing component. The latter has a slot itself where two components are plugged in: one for the category navigation and one for a list of products assigned to the category currently selected in the category navigation component.
The right part of the depiction shows an object diagram demonstrating the decomposition of the page variant on the left in its constituent parts. The relations between ProductPageVariant HeaderSlot, ProductBrowsingSlot and FooterSlot are of type composition, i.e., HeaderSlot, ProductBrowsingSlot and FooterSlot are parts of ProductPageVariant and may be regarded as attributes of ProductPageVariant and, as such, are bound to its lifecycle. The same applies to ProductBrowsingComponent and ContentSlot. Components visually placed within slots are assigned to them via aggregation relations, from a technical point of view. This means, they may be considered as part of the component or page variation the respective target slot is owned by. However, they exist on their own and can be re-used by other components or page variations by simultaneously assigning them to other slots.

CMS Layer Model

Content development takes place in a model-driven manner; i.e., content instances will be created and linked with each other as defined by a model which is logically called "Content Model". The content model in turn represents a structure of elements and relations between them which is created and changed according to certain rules and type restrictions. These types and rules are defined in a further model acting as model for the content model and, since it is a model of the content model, is thus called "Content Meta Model".

The content meta model embodies the core of the entire CMS. All content management and development tools as well as the entire content rendering in the storefront do either directly or indirectly base on or derive from the content meta model. It is part of the IS7 platform and as such is fixed and will not be changed by content developers or editors.

All items at the content instance and content model layer have a counterpart at the next higher layer. These inter-layer relations may be regarded as a 1:n relation with the single part of the relation being the model of the multiple part. This means that one content meta model element has several counterparts at the content model layer and each content model element has several counterparts at the content instance layer. Similar to classes and their objects in an object-oriented programming language, the inter-layer relation in the CMS may be also considered as a kind of instance-of relation.

The diagram below gives a more detailed view of the CMS layer model, in particular with respect to the physical representation of the single items at each layer and their storage location. Another aspect covered by the diagram is which layer is relevant at development time, i.e., which items are created or maintained in Intershop Studio, and at runtime, i.e., which items are managed throughout the back office and used in the storefront.

The content meta model has been created by using the Eclipse Meta Modeling Framework (EMF). Its essentials are encoded in pagelet.ecore, a file stored in the cartridge bc_pmc(Pagelet Model Component) and based on Ecore in EMF which acts as meta model for the content meta model. In addition, there is a class-based representation of the content meta model where the public part resides in the package com.intershop.component.pmc.capi.pagelet.definition. The code has been created with code generators coming with EMF using pagelet.ecore as input and slightly augmented with a few customizations. The class representation is necessary to make the content meta model accessible to the application server at runtime.

In the same way as the meta content model layer, the content model layer is divided into file-based and class-based items. The content model files have the extension .pagelet2 and are instances of pagelet.ecore. They embody the construction plans for all the elements at the content instance layer, i.e., each content instance has a counterpart at the model layer. One model file can hold more than one of these construction plans. The terms used for them are either <ContentInstance> definition or <ContentInstance> type, e.g., slot definition or page type. A content model file is stored in a dedicated folder called pagelets within a cartridge. The cartridge holding all content model files coming with the B2C application in IS7.1 is sld_ch_b2c_cm. However, the overall content model may be spread over several cartridges. At server startup, all cartridges are scanned for content model files which will then be loaded into memory. There, they are represented as instances of the class-based meta model, i.e., instances of the interface in com.intershop.component.pmc.capi.pagelet.definition.

Qualified Name

Each content model element has exactly one representation in memory per application server. To be able to find such an element, the element needs a unique name. This name is called "qualified name" and has to be unique per cartridge. Content instances use qualified names to refer to their content model elements. Since the basic structure of content model files is XML, the qualified name of an element within such a file is similar to XPath expressions used to identify XML elements. To mark a content element as identifiable, its content meta model element must implement a certain interface, com.intershop.beehive.emf.core.NamedElement that guarantees that all its instances at the content model layer have a name. The qualified name of a content model element is then the concatenation of all element names from the outermost element towards the target element separated by dashes. For example, the qualified name of the slot definition in the following content model file is slot.account.Group.pagelet2-Slot.

<?xml version="1.0" encoding="UTF-8"?>
<pagelet:PageletModel xmlns:pagelet="http://www.intershop.de/pagelet/2010" name="slot.account.Group.pagelet2">
   <slotDefinitions multiplicity="ZERO_MANY" name="Slot">
   <callParameterInterfaces referencedName="some_cartridge:interface.account.Group.pagelet2-Interface" />
   </slotDefinitions>
</pagelet:PageletModel>

The content instance layer is distributed between the database and the ORM cache. As content instances are persistent objects, each one has an entry in the database and one in-memory representation per application server, i.e., one ORM cache entry. As already mentioned, each content instance refers to its content type or definition by its qualified name; the respective attribute holding the reference is definitionQualifiedName. In contrast to content meta model elements and content model elements, there is no direct relation between content model elements and content instances, but only an indirect one via the reference per qualified name. Content instances are completely modeled in EDL; however, the class structure greatly resembles the class model at the content meta model layer.

Mapping of Content Concepts to the Corresponding Technical Counterparts

Here is a summary of all the aforementioned items together with the corresponding concepts