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.
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:
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".
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.
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.
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
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.
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.
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:
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
FooterSlot are of type composition, i.e.,
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
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.
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
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
<?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.
Here is a summary of all the aforementioned items together with the corresponding concepts
Page Entry Point
Category and Product Pages
View Context, Page Entry Point
Category and Product Includes
View Context, Component Entry Point
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.