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:
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
Category2. The context here is catalog browsing with
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
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
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:
Here is a table listing all the resulting views for each product of the example above according to this sequence:
Catalog Product Bundle Page
Catalog Retail Set Page
Product Variation Fallback Page
Catalog Product Bundle Page
Product 5 Page
Product Variation Fallback Page
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.
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,
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
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:
Catalog: This value says that the object context relation is meant for view contexts dealing with catalogs and categories as target objects.
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.
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
contextTypeis 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
Categoryor 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
contextTypewould then be
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.
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:
PageEntryPointDefinitionInclusionwhose instances hold a reference to a page type, and
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:
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.
contentEntryPointDefinition: An element holding a reference to a content entry point definition by specifying its qualified name.
name: Content entry point definition inclusions need to be identifiable so that they can be referred to from within the content instance level. Hence,
com.intershop.beehive.emf.core.NamedElementso that its instances will automatically be supplied with a qualified name. The value of
namehas to be unique in the scope of the enclosing context object relation.
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.
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.
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.
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:
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.
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
ResourceSetand 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.
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:
viewContext:ViewContext: The view context that provides the scope for the page/include search.
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
viewContextInclusionNamedetermines which of these pages/includes is chosen as result.
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.
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.
productBO:ProductBO: In case of a product page/include lookup, the product in question. The category page/include lookup does not use this parameter.
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.
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.
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.