Data islands configuration

Creation and editing of data islands have been substantially revised in 10.4. Data islands are no longer inserted as blocks of HTML in pages or variable blocks instead they are embedded via syntax such as:

:::dataisland-top-5-news-articles:::

and their configuration is implemented in the Data Islands grid explained below. The data islands grid allows you to add, edit and delete data islands all over your site. In addition it allows you to check their usage, clear their caches and also to debug them. By creating a centralised editing point for data islands their performance through caching is improved and data islands implemented in several locations can be edited in a single place. All data island actions are recorded in the audit trail.

The editing grid

The data islands table has the following columns:

Name - The name of the data island. This name is prefixed with 'dataisland-' to reference the dataislands in pages via the triple colon notation. The name must be unique.
XML URL - This is the absolutely or relatively (10.5) addressed URL of the XML file to be used in the data island and is a mandatory field. The field is clickable for testing unless the link contains 'magic' word. The entire URL can be replaced by a reference to a Sitekit variable (added in 10.5) eg :::variable-bbc-news-rss:::
XSL URL - This is the absolutely or relatively (10.5) addressed URL of the XSL file to be used in the data island and is a mandatory field. The field is clickable for testing. If the XSL comes from xsl.sitekit.net it does not need to be digitally signed, otherwise it does. Again this can be replaced by a sitekit variable.
Allowed Parameters - list of parameters allowed to be passed to the XSL and or the XML data island. Only parameters whose names are in the list will be forwarded to the XML feed. This attribute should be used in conjunction with the cachelnMin attribute. Otherwise a unique session ID will be passed by default negating any advantages of caching. Allowed parameters also accept 'all', 'any' or 'none' as arguments. This attribute while optional is recommended especially if the XML URL is on a separate site to stop the passing of Sitekit parameters to an external provider. For new data islands putting in '*' into the allowed parameters while editing or creating a data island will auto-fill the parameters with the defaults.
XML Cache (Mins) - This is the cache expiry period in minutes. The attribute is optional and defaults to 0 (no caching). The acceptable range is integer values from 0 to 36000. The section below deals with caching. Should be used with allowedParameters (above) to avoid cache invalidation by the unique session id.
XSL Cache (Mins) - This is the cache expiry period in minutes. The attribute is optional and defaults to 0 (no caching). The acceptable range is integer values from 0 to 36000.
Transform Cache (Mins) - This is an advanced feature as it will cache without taking account of personalisation. Transform caching is not allowed if the allowed parameters list is empty, 'any', 'all' or contains any 'sitekit_' parameters other than siteid and lang. Note: If used incorrectly with dataislands containing personalised content it may result in a user's details being exposed to more than one user
EXSLT - checkbox - defaults to false. Defines whether the XSLT uses the extended methods provide by eXSLT.
Send Cookies - checkbox, - some web services need cookies for session ID in order to identify whether someone is logged in, this should be ticked then.

The following actions are implemented on the data island table:

edit - clicking on this allows you to edit all of the fields above where a data island is used.
usage - usage produces a popup window showing all the locations where a data island is used.
flush - flushes the data island cache on all its instances, allows all instances to pick up any changes made during editing. An admin popup warning is presented before the flush takes place.
delete - deletes the data island. An admin popup warning is presented before the delete takes place. A data island cannot be deleted while in use, i.e while having any entries in the usage table.
debug - clicking on the 'name' field of the data island row produces a new window with various debug elements and outputs to help with debugging.

The previous data islands implementation had been deprecated but for reference its preserved here.

Parameter passing into XSL

This is achieved with reference to the following article https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-1.1/ts9by56w(v=vs.71) using the XSLT Argument list.

The following parameters are loaded as an xslt argument list so are available in the xslt:

form, prefixed form_
querystring (both submitted and appended to to the xsl url, prefixed qs_
Sitekit parameters, prefixed sitekit_ (sitekit_LoggedInUser, sitekit_LoggedInUserName, sitekit_SiteID, sitekit_SID, sitekit_GroupID, sitekit_Groups, sitekit_pagename, sitekit_EditorialID, sitekit_Lang, sitekit_ShortcutID, sitekit_AssetID)
Cookies, prefixed cookie_

Because the same parameter name can be used both in form and querystring the parameters are prefixed to distinguish between them so for example ID=7 passed in the querystring will be available as qs_ID

You cannot load the same parameter more than once so having the following querystring page.htm?ID=6&ID=7 would throw an error. All but the first value are ignored.

Using parameters in an XSLT would be as follows:

<xsl:param name="sitekit_pagename"/>

<xsl:param name="qs_ID"/>

<xsl:template match="/rss">

xPage: <xsl:value-of select="$sitekit_pagename"/><br />

ID: <xsl:value-of select="$qs_ID"/>

The XSL parameters can be put to various uses, for example you can pull out content from specific XML nodes based on values from the sources listed above. This could allow for news XML content to be listed in a paging format with e.g. 10 items listed per page – clicking on each would take the user to the full news item detail. Or, if an XML source does not allow filtering based on parameters this can be simulated to allow a summary listing page and a full detail page to be generated from the one XML source. For example:

This XSL example lists titles from an RSS news feed:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="xml" encoding="UTF-8" omit-xml-declaration="yes" indent="yes"/>
  <xsl:template match="channel">
    <ul>
      <xsl:for-each select="item">
        <li><a href="/details.htm?id={guid}"><xsl:value-of select="title" /></a></li>
      </xsl:for-each>
    </ul>
  </xsl:template>
</xsl:stylesheet>

As the code shows, the value of the guid element is passed to the details page as a querystring parameter called id. This value is then pulled out into the XSL on the details page which searches the XML for an item with a matching guid value. This is shown here:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="xml" encoding="UTF-8" omit-xml-declaration="yes" indent="yes"/>
  <xsl:param name="qs_id" />
  
  <xsl:template match="item">
    <xsl:if test="guid=$qs_id">
      <h2><xsl:value-of select="title" /></h2>
      <p><xsl:value-of select="description" /></p>
    </xsl:if>
  </xsl:template>
  
  <xsl:template match="channel">
    <xsl:apply-templates select="item" />
  </xsl:template>
</xsl:stylesheet>

The id value is pulled into the XSL using <xsl:param name="qs_id" />. It is then called by using the $ prefix, the same way as XSL variables are called, e.g. <xsl:if test="guid=$qs_id">.

XSLT 2.0

From version 12, the CMS supports XSLT 2.0 stylesheets.

To use XSLT 2.0 in your XSL stylesheet, simply change the version to 2.0:

<xsl:stylesheet version="2.0">
    <xsl:template match="channel">
    </xsl:template>
</xsl:stylesheet>

This has no effect on any existing transforms, as all existing XSL files are processed as either XSLT 1.0 or EXSL, as before.

Data island loops

There are checks in place to make sure that the xml and/or xsl URLs cannot refer to the calling page. If this happens it outputs an error message. 'The XML or XSL document references the calling page creating recursion'. Added in 11.0

The checks work whether the calling page is referenced directly or via its REST url equivalent.
It checks whether the url references the xml version of the calling page.
It checks whether the data island is configured on the Data Island Screen or via the xmlconsumer sniplet.
It checks whether the url references the calling page using a different protocol, e.g. https.
It checks whether the url references the page via an alternative domain name.

Magic Word Pre-Replacement in XSL (v12.0)

When magic words are used in XSL files as part of data islands, the magic words are normally replaced after the XSL transform has taken place. It is possible to insert the prefix 'pre-' into a magic word within an XSL file to have it replaced before the XSL file is passed to the XSL transform. This allows the XSL to access the value of the magic word, instead of seeing the magic word itself.

<xsl:if test="':::pre-protocol:::' = 'https'">protocol magic word pre-replaced!</xsl:if>

Reference library