Intershop 7 provides two kinds of adaptability of standard applications:
The same extension point may call a different list of extensions depending on the execution context (cartridge list of executed application type). Hence, particular extensions can be reused in different application types.
The extension engine is responsible to load the extension model files (suffix "
.extension"), that are responsible to register the particular code artifacts at the defined extension points. Such a file contains an extension model with a name, which binds one or more extensions of different types to the particular extension points. The integer value in the extension bindings is used to sort the overall extension list:
Place within a code artifact where other code artifacts can be plugged in.
Extension Point Type
Defines the behavior of the extension point. Currently, there are three types available for the particular code artifacts: Java, ISML template and pipeline.
A code artifact which plugs into an extension point.
The following sub-chapters explain the existing extension types in more detail.
Extension point nodes are used to define extension points within pipelines. The node requires the extension point identifier, which needs to be unique within the pipeline. Further, (since Intershop 7.3), it is possible to define the parameters and return values that are delivered to and returned from the extension pipelines. An extension pipeline is of type "extension" and needs to be finished with an end node. Interaction nodes are not supported and do not make sense. If the name of end node is empty or is "next" or has any other name than "error" (case insensitive), then the extension point continues calling other extension pipelines. Error end nodes interrupt the execution of the extension point node. Thus, the extension point node has two out connectors, one is the error connector and one "next" connector.
The extension model files reference an extension point within a pipeline by using the pipeline name and the extension point identifier (e.g. "ProcessProduct-ProductUpdated").
The process of creating pipeline extension points and extension pipelines is explained in the corresponding cookbook .
Usage of the error connector
Here is an example of using the error connector:
Assuming a business object creation is extensible by providing an appropriate pipeline extension point. If one of the extension pipeline calls ends with an error end node, the business object creation basically failed. Using the error connector of the extension point node the pipeline developer has the ability to produce an appropriate business error message. Additionally, controlling a transaction is easier - it can begin before the extension point node; the commit will be placed somewhere in the branch of the next connector and the rollback is performed in the branch of the error connector.
If an exception is thrown within the execution of the extension pipeline, this exception is handled as in any other pipeline:
ISML templates define extension points by using the
isinclude tag with the attribute
<ul> <isinclude extensionpoint="Tabs"> </ul>
The ISML template processor includes every ISML template which is registered in current execution contexts to this extension point. The extension model files reference an extension point in an ISML template via template name and extension point identifier (e.g. "product/TabBar-Tabs");
The process of creating ISML template extension points and appropriate template extensions is explained in the corresponding cookbook .
Java class extension points provide the ability to plug custom code snippets into an existing functionality written in Java. To define an extension point, the method in Java which processes the extensions must be annotated appropriately.
The process of creating Java extension points and extensions which plug into this extension point is explained in the corresponding cookbook .
It is possible to create new extension point types for other artifacts existing in Enfinity or developed later. To understand how a new extension point type is added, some knowledge about the extension API is required.
The diagram shows two packages:
The cartridge pipeline is just part of the diagram to show how the integration of a "real" extension works. The cartridge pf_extension basically defines the infrastructure to work with extensions: an engine, a context and an extension point type.
ExtensionPointType is used to declare an extension point type. Extension point types are registered at the extension engine. One extension point type instance corresponds to the type attribute used in extension point bindings created in Intershop Studio. A new extension point type must be introduced by implementing the corresponding extension point type class and register it at the extension engine. The extension engine can look up extensions of registered extension point types only. The extension point type is also responsible to create an extension instance of a given class. When the extension engine determines all extensions of a given extension point, it invokes the corresponding method to create the extension instances. For that purpose, the implementation of an extension point type instance is parametrized with the extension interface class.
PipelineExtension obviously defines methods to get a pipeline name and a start node name. The
PipelineExtensionPoint creates an instance of
PipelineExtension; that is why this class is parametrized accordingly. The instance implementing the interface
PipelineExtension is created by the pipeline extension point type when requested.
An example of the implementation of a custom extension point type is given in the cookbook .