Introduction

View contexts are meant to associate arbitrary business objects with content in the form of pages or includes to supply them with individual visual representations in the storefront.

View contexts as a concept comprise three parts:

1. Context: A context is the environment in which certain objects are shown. It may be a virtual concept, e.g., shopping cart or express shop, having no physical representation but perhaps programming artifacts such as ISML templates or pipelines, or a concept connected with specific business objects. In the latter case the context is then parameterized with business objects. For instance, if one regarded catalog browsing as a context, it could be made more specific by parameterizing it with a catalog or category. However, a context "catalog browsing" without a catalog or category would be self-sufficient as well and could be thought as simply matching all catalogs and categories.
2. Object: Here, object stands for a type of business object where the corresponding instances need to be displayed in certain contexts. It is an identifier that is internally mapped to a concrete persistent object type by convention. All the instances of that type are then considered as target objects of a view context.
3. View: The view represents the content element with which objects eventually will be rendered in a certain context of the storefront. As pages and includes are the preferred means to link content to the storefront, a view will be either of them. There are four types of views:
   1. Object-specific views: As their name implies, object-specific views are meant to render individual objects within the scope of a view context. If a content developer creates such a view, it will be explicitly bound to the object and the view context by a special assignment object.
   2. Constraint-based views: Although the objects a view context aims at are of the same type, they may be subdivided into subsets according to certain criteria. View contexts allow to provide a specific view for each of these subsets. This way, the content developer is not required to provide a specific view for each target object. For instance, products may be divided by their product type so that a corresponding view context could then come with individual pages or includes for retail sets, product bundles, product variations and so on. Like object-specific views, constraint-based views need an object they can be bound to even if they are meant to render a set of objects. In the case of product-type-specific views of a view context meant for catalog browsing, this could then be the catalog or categories acting as context parameters.
   3. Parent-based views: Many objects have a kind of parent relation with objects of the same or another type. These objects can be divided according to their parent object. E.g., products are usually attached to at least one category. By attaching views to categories, all their products can then be rendered differently in the storefront. On top of that, categories have a parent relation among themselves so that it is possible to attach a view to a category in the scope of a view context. This means, all the products assigned to sub-categories of this very category will inherit its view. Moreover, parent-based views may be combined with constraint-based views. A content developer may want category-specific views for products which are further specialized according to the type of products.
   4. Fallback views: Fallback views come into play when a view context does not have object-specific, constraint-based or parent-based views for an object that is to be rendered. They make sure that each target object of a view context can be rendered in the storefront within its scope at any time. If there is no specific, constraint-based or parent-based view for an object, a matching fallback view of the view context will be used for rendering.

The picture below carries on with the example of a view context meant for catalog browsing whereas the target objects are products that are subdivided into retail sets, product bundles and product variations. The products are all assigned to one of the two sub-categories of Catalog acting as parents of them. Catalog is the parent of Category1 and Category2. The context here is catalog browsing with Catalog, Category1 and Category2 as possible context parameters. If one of the products was to be displayed in the storefront but was not assigned to a category, one of the fallback pages of the view context CatalogBrowsing would be selected for rendering. Since the products are partitioned into three sub-sets according to their product type and each type needs a different kind of view in the storefront, CatalogBrowsing has three fallback views, one for each product type. Category2 has a parent-based view for its products which is additionally a constraint-based view since it is only able to render retail sets. Catalog, the parent of Category2, has two constraint-based views which are also parent-based views for Category1 and Category2 as well as all the products assigned to the two categories. As none of the products and categories has a view being able to render product variations, the corresponding fallback page of CatalogBrowsing, ProductVariationFallbackPage, will always take care of them.

When an object is to be rendered within the scope of a view context, the logical sequence for view selection is:

1. Object-specific views,
2. Constraint-based and/or parent-based views,
3. Fallback views.

Here is a table listing all the resulting views for each product of the example above according to this sequence:

Additionally to the view fallbacks within a view context, it is also possible to establish fallbacks between different view contexts to extend the set of potential views for certain target objects. The target objects of the involved view contexts must then be of the same type. The means for linking view contexts are view context parameters which actually are configuration parameters of a certain type allowing them to refer to view context instances.

Model

ContextObjectRelation

Like most of the other content elements, view contexts are defined and established by providing models of a dedicated meta-model type. Here, the corresponding meta type is ContextObjectRelation. Each view context instance is based on a context object relation. As indicated by the extension relation to ConfigurationParameterDefinitionCtnr, context object relations may have configuration parameters. Likewise, ContextObjectRelation extends CallParameterDefinitionCtnr which means that context object relations may define call parameters. View context instances based on such context object relations expect a parameter value for each of those call parameter definitions in their execution environment. The call parameter definitions may be represented by explicit call parameter definition elements or by inheriting them via references to call parameter interfaces.

The corresponding element for context object relations in content model files is contextObjectRelations.

Attributes:

• name: Each context object relation needs a name that has to be unique in the scope of the enclosing content model element.
• page: This flag indicates whether the views of inheriting view contexts need to be pages or includes. Combinations of them are not allowed.
• objectType: This attribute holds an identifier for the type of the intended target objects of inheriting view contexts. Right now, there are only two possible values:
  1. Catalog: This value says that the object context relation is meant for view contexts dealing with catalogs and categories as target objects.
  2. Product: This value says that the object context relation is meant for view contexts dealing with products as target objects.
• systemManaged: This attribute determines how the lifecycle management of inheriting view context instances will take place. If its value is true, there will be exactly one view context instance per content repository as long as the context object relation is accessible to the application the repository belongs to and whose lifecycle is completely handled by the system. A back office user will not be able to remove it. The ID of this system-managed view context will be the same as the qualified name of the context object relation. However, it will still be possible to use the context object relation as base type for normal user-managed view contexts.

Elements:

• contextType: This attribute is kind of ambiguous as it might be regarded as the context described initially, but this context is represented by a complete view context instance itself. The attribute contextType is merely meant to steer in which content section of certain business objects the context object relation is shown when a user wants to create views for them. Right now, only products and categories may be supplied with views, so the possible values are Product, Category or comma-separated combinations of both. The latter is needed to provide parent-based and/or constraint-based views. For instance, a content developer might want to supply products with specific views as well as define the view at a category they are directly or indirectly attached to. The value of contextType would then be Category,Product or Product,Category.
• pageletEntryPointPipeline: Each context object relation is required to come with a so-called "pagelet entry point pipeline" which will be used when an object is about to be rendered in the scope of a view context. The render logic will obtain the context object relation from the view context and ask it for its pagelet entry point pipeline. This pipeline will then be fed with all the call parameters and configuration parameters of the view context and is expected to return the proper view which will eventually render the object. The pipeline alone determines which view will be returned. It may be, as described in the example above, an object-specific, constraint-based, parent-based or fallback view or follow a totally different strategy. The B2C application of IS7 comes with a preconfigured lookup strategy which, on the whole, matches the behavior described in the example but can still be customized by using IS7's extension mechanism.

ContentEntryPointDefinitionInclusion

As already outlined in the previous sections, all views of a view context form a hierarchy with each view existing at one of its levels. In the catalog browsing example, these hierarchies would be all object-specific views at the lowest level, the category hierarchy up to the catalog would make up the next levels and the global fallback views the top level. The view fallback sequence is always from the most specific view up to the generic views. How the hierarchy is computed may completely differ depending on the intended target area of a view context. As in the example, each hierarchy level, except the one at the top related to the fallback views, may be bound to concrete business objects composing themselves a hierarchy, but this is not necessarily always the case. The hierarchy might also be somehow computed according to rules not directly encoded by direct relations between objects. However, a context object relation has to determine how many views its view contexts may provide for an object at each hierarchy level and of which type these views have to be. The means to do so are instances of the meta model class ContentEntryPointDefinitionInclusion. As view contexts are restricted to either page or include views, the ContentEntryPointDefinitionInclusion has two sub-classes:

1. PageEntryPointDefinitionInclusion whose instances hold a reference to a page type, and

2. ComponentEntryPointDefinitionInclusion whose instances refer to an include type. The corresponding model element is contentEntryPointDefinitionInclusions. The attribute type determines of which of the two sub-classes such elements are instances. Here is an example of includes:

   <pagelet:PageletModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:pagelet="http://www.intershop.de/pagelet/2010" name="viewcontext.include.category.pagelet2">
     <contextObjectRelations name="viewContext" page="false" objectType="Category" systemManaged="false">
       <contextType>Category</contextType>
       ...
       <contentEntryPointDefinitionInclusions xsi:type="pagelet:ComponentEntryPointDefinitionInclusion" name="includeCategory">
         <contentEntryPointDefinition referencedName="include.category.standard.pagelet2-include"/>
       </contentEntryPointDefinitionInclusions>
     </contextObjectRelations>
   </pagelet:PageletModel>
   

   Here is a context object relation restricted to pages:

   <?xml version="1.0" encoding="UTF-8"?>
   <pagelet:PageletModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:core="http://www.intershop.de/core/2010" xmlns:pagelet="http://www.intershop.de/pagelet/2010" name="viewcontext.page.category.pagelet2">
     <contextObjectRelations name="viewContext" page="true" objectType="Category" systemManaged="false">
       <contextType>Category</contextType>
       ...
       <contentEntryPointDefinitionInclusions xsi:type="pagelet:PageEntryPointDefinitionInclusion" name="pageCategory">
         <contentEntryPointDefinition referencedName="page.category.pagelet2-page.category"/>
       </contentEntryPointDefinitionInclusions>
       ...
     </contextObjectRelations>
   </pagelet:PageletModel>

The context object relation in the object diagram below assumes that its target objects are subdivided into three subsets:

1. Product variations (PV),
2. Product bundles (PB) and
3. Retail sets (RS).
   Hence, it has to define three content entry point definition inclusions so that its instances are able to provide different views for each subset of the target objects.

The content entry point definition inclusions of a context object relation do not necessarily need to refer to different content entry point definitions. The actual visual distinction for each product type will be made at content instance level by attaching different pagelets to each view. This approach can be regarded as an application of the Composition over Inheritance Principle, i.e., provide as few page or include types as possible, which in turn have to be rather generic, but, instead, will have more instances.

The following diagram combines the context object relation above with all the views belonging to a view context that are an instance of the context object relation. The views belonging to the view context are grouped according to their hierarchy level. The dashed arrows depict the view fallback for each target object from the object itself, along the category structure up to the global fallback views of the view context. The white boxes represent gaps where there is one of the three possible views per object missing. The objects making up the hierarchy are the target objects, i.e., products, and direct or indirect parent objects of them, i.e., the category structure the products are bound to.

Elements

• contentEntryPointDefinition: An element holding a reference to a content entry point definition by specifying its qualified name.

Attributes

• name: Content entry point definition inclusions need to be identifiable so that they can be referred to from within the content instance level. Hence, ContentEntryPointDefinitionInclusion extends com.intershop.beehive.emf.core.NamedElement so that its instances will automatically be supplied with a qualified name. The value of name has to be unique in the scope of the enclosing context object relation.

View Context Parameter Type

The configuration parameter type model types.pagelet2 in the cartridge bc_pmc comes with a configuration parameter type ViewContext. This type allows for configuration parameters that reference view context instances at content instance level. Thus, the parameters enable page or include lookup strategies for particular business objects across several view context instances. By default, a configuration parameter derived from a configuration parameter definition referring to ViewContext lists all view context instances residing in the content repository it lives in. However, these instances may be restricted by the type, i.e., the context object relation, they are based upon.

Here is an example showing how such a model could look like:

<?xml version="1.0" encoding="UTF-8"?>
<pdm:PageletModel xmlns:pagelet="http://www.intershop.de/pagelet/2010" name="views.pagelet2">

  <contextObjectRelations name="CategoryContext" page="false" objectType="Category">
     ...
     <configurationParameterDefinitions name="ViewContextFallback" localizable="false"
        typeReference="types.pagelet2-ViewContext">
         <parameterBindings xsi:type="core:ParameterValueBinding"
             name="ContextObjectRelations" value="views.pagelet2-SubCategoryContext"/>
     </configurationParameterDefinitions>
     ...
  </contextObjectRelations>
  <contextObjectRelations name="SubCategoryContext" page="false" objectType="Category">
     ...
  </contextObjectRelations>

</pdm:PageletModel>

The context object relation has to be referred to by its qualified name. To specify more than one context object relation, the qualified names have to be separated by a comma.

PO

com.intershop.component.pmc.capi.viewcontext.ViewContext, the public interface of view contexts at the content instance level, inherits from com.intershop.component.pmc.capi.pagelet.ConfigurationParameterCtnr and as such its instances may have several configuration parameters.

The fallback pagelet entry points of a view context are bound to it by special assignments of type com.intershop.component.pmc.capi.viewcontext.assignment.PageletEntryPointViewContextAssignment. The number and model types of the fallback entry points are determined by the content entry point definition inclusions owned by the context object relation the view context is based upon. That is why each fallback assignment refers to such a content entry point inclusion.

As for business-object-specific pagelet entry points, the pattern is the same as with fallback pagelet entry points. They are bound to the target business objects and view contexts via assignments of type com.intershop.component.pmc.capi.viewcontext.assignment.PageletEntryPointViewContextObjectAssignment. The interface has a type parameter that becomes bound to concrete types in the implementing classes. Right now, there are only two, one for products and one for categories. The type constraints for pagelet entry points per view context and business object are the same as for fallback pagelet entry points and their view contexts.

Rendering

Regardless of whether an object (e.g. a product, a category) is to be rendered at the end of a pipeline or within an ISML template, it has to be passed on to the corresponding render artifact. Neither the pipeline nor the ISML module do specify an explicit parameter for the object. Instead, the context object relation of the corresponding view context has to specify the object as one of its call parameters. The object is then expected to be available as an entry in the pipeline dictionary of the invocation environment with a key similar to the call parameter name.

Pipeline

Old Mechanism (deprecated since IS 7.6)

The pipeline ViewViewContext-Start in the cartridge sld_pmc is meant to render arbitrary business objects via view contexts. It expects the desired view context in its pipeline dictionary in two ways:

1. either directly as instance, the dictionary key is ViewContext, or
2. indirectly by its semantic key, the dictionary key is then ID and ResourceSet.
   In the latter case, the required content repository domain will be automatically determined via the current application. The pipeline is private and as such cannot be invoked directly from outside of pipelines.

New Mechanism

The generic interaction end node RenderSystemViewContext in cartridge sld_pmc is meant to ease the pain of unnecessary dictionary key aliasing. Previously the pipeline ViewViewContext-Start was incapable of in-place call parameter mapping to conform to the expected rendering dictionary. Now with generic pipeline nodes that can be done easily. All you have to do is to refer to the system-managed context object relation with a fully qualified name, e.g., app_sf_responsive:viewcontext.page.category.pagelet2-ViewContext. Intershop Studio's Visual Pipeline Editor displays the expected call parameters for further editing.

In addition to RenderSystemViewContext there is also a node named GetPageletEntryPointFromSystemViewContext for rendering a view context. For a pipeline developer it behaves quite the same as RenderSystemViewContext in terms of call parameter handling. But instead of subsequently passing the determined pagelet entry point to the rendering queue, it returns it to the pipeline dictionary for further processing. Consider it as a 'pre' rendering phase where custom logic can be applied to what will actually be used when RenderSystemViewContext is called.

In pipelines it is expected that only qualified names denoting a system-managed context object relation will be used along with above nodes. ViewViewContext-Start is still in place for to ensure backward compatibility (use only if unavoidable) none system-managed item rendering.

ISML

The module to trigger object rendering via view contexts in ISML is ISViewContext. It has the same parameters as ViewViewContext-Start of which one has to be present when it is executed:

• ID: The identifier being part of the semantic key of the view context. Along with ResourceSet and the content repository domain a view context object is identified. The latter will automatically be determined via the current application.
• ResourceSet: Usually the cartridge ID of the context object relation that uniquely identifies a system-managed view context. If ID is not denoting a system-managed view context, use the cartridge ID displayed in the View Contexts list hover shown in the Commerce Management application.
• ViewContext: The view context instance ready for rendering.

Object Rendering via View Context

Page/Include Lookup in B2C Application

The pagelet entry point lookup pipelines of the context object relations coming with the B2C application of IS7 rely on lookup strategies which are configurable and interchangeable at application level. They are tailored to serve the display of categories and products in the storefront and, as such, work across several view contexts. The base interface is com.intershop.sellside.application.b2c.capi.lookup.PageletEntryPointLookupStrategy. Right now, it has two implementations in sld_ch_b2c_app, one for products and one for categories. They are retrieved via the component framework. There is one contract for the lookup of product pages/includes, ProductPageletEntryPointLookupStrategy, and one for category pages/includes, CategoryPageletEntryPointLookupStrategy. At pipeline level, the lookup implementations are used by the pipelet GetPageletEntryPointByViewContext, which eventually returns the pages/includes for a product or category.

lookupPageletEntryPoint, the only method of PageletEntryPointLookupStrategy, has five parameters, which are implicitly given to the lookup strategy implementations if one configures the pipelet GetPageletEntryPointByViewContext properly and serves it with the right input parameters in the lookup pipelines:

1. viewContext:ViewContext: The view context that provides the scope for the page/include search.
2. viewContextInclusionName:String: A view context may have several page/includes per target object based on one of the content entry point inclusion definitions of the context object relation the view context has been derived from. The value of viewContextInclusionName determines which of these pages/includes is chosen as result.
3. domain:Domain: The domain of the content repository to be searched for pages/includes. Content repositories shared with the given repository are taken into account automatically.
4. categoryBO:CatalogCategoryBO: In case of a product page lookup, the category that should be used as starting point for the subsequent search if there does not exist a page/include for the given product. Otherwise, the category for which the strategy is expected to return a page/include.
5. productBO:ProductBO: In case of a product page/include lookup, the product in question. The category page/include lookup does not use this parameter.

Product Page/Include Lookup

Apart from the view context and the qualified name of the inclusion definition, the product page/include lookup takes a product and, optionally, a category as input values. At first, it tries to obtain a page/include directly assigned to the product. If there is none, it asks a category passed to lookupPageletEntryPoint for a page/include in the same view context. If there is no category, the default category of the product is used. If the category still has no page/include, the category path up to the root category starting with the parent category of the current category will be traversed until a page/include has been found. If this procedure still returns no page/include, the respective fallback page/include of the view context will be returned.

Category Page/Include Lookup

The category page/include lookup works similar to the one for products, in that it traverses the category path starting with the category in question. What is different is that the view context is asked for a sub-category view context encoded as view context reference in one of its configuration parameters if there is no category-specific page/include in the scope of the view context. Such view context references are meant to allow a category to specify a different look for all its sub-categories. The content editor has to create a page/include for the category in the scope of the sub-category view context. If the lookup cannot find a specific page/include for one of the sub-categories, it simply switches to the sub-category view context for the lookup further up the category path. If no page/include is found, the lookup switches back to the original view context and returns its fallback page/include according to the provided content entry point definition inclusion.