If you include CoreMedia fragments into WCS pages, these fragments might contain links to WCS pages; a link to an Augmented Category, for example. Depending on the scenario that you use, this link should led to a page rendered by the CAE (content-led scenario) or to a page rendered by the WCS (commerce-led scenario). The latter is named "deep link".
A use case for deep links might be the following: You have an existing commerce solution with carefully styled category and product pages. While you want to switch to CoreMedia DXP 8 in order to enhance your site with editorial content, there is no need to port the commerce pages to CoreMedia DXP 8. Instead, you want to reuse the existing pages (possibly enhanced with CoreMedia DXP 8 fragments).
Configuring deep links
CoreMedia DXP 8 supports two settings to switch to deep links for categories and products:
livecontext.policy.commerce-product-links
livecontext.policy.commerce-category-links
The settings are at the root channel of each site. The default setting is true
, which means that the CAE creates
deep links to the product or category pages of the IBM WCS. However, for links to other content types, such as
HTML
, CSS
or JavaScript
, links to the CAE will be generated. Also, URLs to
dynamic resources (UriConstants.Prefixes.PREFIX_DYNAMIC
) won't be converted
to JSON. See Section 5.6, “Enabling Preview of Commerce Category Pages in Studio” to learn how to enable the preview for WCS pages in Studio.
The settings are evaluated by the LiveContextPageHandlerBase
and its subclasses.
If a setting is true
, the corresponding @Link
method creates links to IBM WCS,
so there is no need for a matching @RequestMapping
method.
If it is false
, the @Link
method creates CAE
links. So you must keep the according @RequestMapping
method in sync with changes to the URL pattern
and provide (or customize) the ProductPageHandler
or ExternalNavigationHandler
classes. See also the Section 4.3, “The CAE Web Application” in CoreMedia Content Application Developer Manual for request handling and
link building.
Format of Deep Links
Each lc:include
requests an HTML fragment via HTTP from the CAE. Every link of a fragment that
is requested by the WCS from the CAE is processed by LiveContextLinkTransformer
classes.
The transformer is only applied for fragment requests.
Depending on the document type the link should be generated for, an absolute CAE URL is generated or a JSON string is returned.
Each of these JSON objects contains at least the values of the constants LiveContextLinkResolver.OBJECTTYPE
and
LiveContextLinkResolver.RENDERTYPE
and the ID of the content.
For example, the HTML fragment contains a link to a CMArticle
document. Instead of rendering the regular link,
for example
http://localhost/blueprint/servlet/page/perfectchef/magazine-spring/spring-salads-1888
the corresponding Link generated by the LiveContextLinkResolver
would look like:
a href="<!--CM { "id":"cm-1696-1888", "renderType":"url", "externalSeoSegment":"spring-salads-1888", "objectType":"content"} CM-->" ...
The CoreMedia Fragment Connector
will parse the JSON, identify the object type and rendering type and apply a template to render a commerce link that
points to the parameterized Struts action CoreMediaContentURL
. For the given example, the template Content.url.jsp
will be used,
applied by the pattern "<OBJECT_TYPE>.<RENDER_TYPE>.jsp". The JSP file will render a commerce URL afterwards:
http://localhost/webapp/wcs/stores/servlet/CoreMediaContentURL? storeId=10202&externalSeoSegment=spring-salads-1888& urlRequestType=Base&langId=-1&catalogId=10051
Note | |
---|---|
The SEO feature has not been configured for this example, otherwise the |
Other templates are located in the folder workspace\Stores\WebContent\Widgets-CoreMedia\com.coremedia.commerce.store.widgets.CoreMediaContentWidget\impl\templates
by default.
The path is configurable via property com.coremedia.widget.templates
in coremedia-connector.properties
. New templates can be added by
extending the CMObjectLiveContextLinkResolver
in the Blueprint workspace. Custom object types can be added, depending on the document type of the content or its property values.
Also, additional rendering types can be defined for an object type. Using this templating mechanism, it is possible to support different layouts for content depending on its context.