Develop > Presentation layer > Work with JSP pages > Storefront customization tools > WebSphere Commerce Flow infrastructure

WebSphere Commerce Flow Repository: Site components

The WebSphere Commerce Flow Repository describes a set of JSP pages and the relationships among them. The JSP pages are grouped into the following abstract component hierarchy:

Each component has an interface, and each interface can have one or more implementations. The repository must contain at least one top-level interface for the site and at least one implementation of that interface. An interface describes how to enter and leave the component by specifying entry-ports and exit-ports. An implementation specifies the interfaces that it contains, and the following implementation aspects:

For example, the following XML fragment describes the ShoppingArea area component of a store:

<area id="ShoppingArea"/> 
<interface id="ShoppingArea.i1" component-id="ShoppingArea">    
<entry-port id="ShoppingArea.i1.e1"
<entry-port id="ShoppingArea.i1.e2"
<implementation id="ShoppingArea.i1.impl1"
<component-interface id="ShoppingArea.i1.impl1.ci1"
interface="CheckoutSection.i1" always-enabled="yes"/>    
<entry-port-map id="ShoppingArea.i1.impl1.epm1"
<entry-port-map id="ShoppingArea.i1.impl1.epm2"

The actual-page components, found at the bottom of the component hierarchy, represent JSP pages of the site. Each actual-page component has an actual-page-interface, representing the links in the JSP page as exit-ports. For example, the following XML fragment describes the ActualSingleShippingAddressPage actual page of a store:

<actual-page id="ActualSingleShippingAddressPage"
<actual-page-interface id="ActualSingleShippingAddressPage.i1"
<exit-port id="ActualSingleShippingAddressPage.i1.xNext"

In addition to JSP pages, WebSphere Commerce Flow Repository can describe non-JSP and non-HTML Web assets such as style sheets or images. These assets are represented by virtual-file components. Each virtual-file component can have one or more virtual-file-implementations. In the following example, the virtual-file mechanism specifies the possible paths to the image color directory:

<virtual-file id="vfile.color"/>
<virtual-file-implementation virtual-file-id="vfile.color"
url="images/colors/color1/" id="vfile.color1.dir"/>
<virtual-file-implementation virtual-file-id="vfile.color"
url="images/colors/color2/" id="vfile.color2.dir"/>
<virtual-file-implementation virtual-file-id="vfile.color"
url="images/colors/color3/" id="vfile.color3.dir"/>

The repository enables a site to be built in many different ways, because for any component there can be several available implementations. Each implementation can describe a different flow or, for virtual-file components, a different style. For example, one implementation of the StandardCheckoutSubsection component might allow for splitting the order during the checkout, while another implementation might not. Only one implementation of a component can be active for a particular configuration of the store. That is, allowing the directory path in the preceding example to be determined at run time. The choice of which implementation is active at run time is conveyed by the features aspect of the repository.

Related concepts

WebSphere Commerce Flow infrastructure

WebSphere Commerce Flow Repository: Configurable features