In this example, we have a collection of material which we want to make available to users: whitepapers, articles, tips etc.  We want to group these by material and show the relevant subheading when this changes, but avoid redisplaying the heading if it remains the same, say:

Whitepaper

…

…

Article

…

…

As per other examples, the key to doing this is to ensure we have the collection sorted correctly before we consider displaying them:

<xsl:apply-templates select="[list of items being processed]">
<xsl:sort select="./type"/>
<xsl:sort order="descending" select="substring(./created,7,4)"/>
<xsl:sort order="descending" select="substring(./created,4,2)"/>
<xsl:sort order="descending" select="substring(./created,1,2)"/>
</xsl:apply-templates>

At this point we have a set of items in ascending alphabetical types, reverse ordered by date.

We then call the familiar block to begin processing.

There is now some logic required here to say, if repeat type do not display, if a new type display.

In a scripting language, the obvious solution is to store the type in a variable, and do something if the new type differs from the last stored type.

Restrictions on <xsl:variable> mean we cannot do this.

Loosely, in XSLT position() translates to count [forwards].  XLST has a function that is similar to ‘count backwards’ which is preceding-sibling [OK, it means invert the node set and count forwards, but you get the idea].

Therefore by saying preceding-sibling::*[1]/type XPath expression say “go to the first preceding sibling, then get its type element’s contents” and the expression provides a ready means of testing “is the current value the same as the last one”.

It is worth pointing out that this is a sophisticated function, there are similar ones such as following-sibling, preceding, ancestor, or ancestor-or-self which may be more appropriate to the use required.

It is also important to note the use of ‘*[1]/type’.  The * is a wildcard and this would not work if there were multiple child elements type within the given element.  The [1] is important too as this means go-back-one: or, more accurately, reverse the list and read the next … If the [1] was omited, the expression would say, look backwards anywhere in the list.

Finally, reading backwards would return a null value if the top of the list was reached, so a failsafe is required to make sure we are not at the top of the list.

<xsl:choose>
<xsl:when test="position() = 1">
<!-- display the type-->
<xsl:value-of select="./type"/>
</xsl:when>
<xsl:when test="position() &gt; 1">
<!-- only read backwards now we have read at least one record -->
<xsl:if test="./type != preceding-sibling::*[1]/type">
<!-- only if the type has changed-->
<xsl:value-of select="./type"/>
</xsl:if>
</xsl:when>
</xsl:choose>

The following  should do the work

<xsl:apply-templates select="[some repeating datum]">
<xsl:sort order="descending" select="substring(//somedate,7,4)"> <!-- year-->
<xsl:sort order="descending" select="substring(//somedate,4,2)"> <!-- month-->
<xsl:sort order="descending" select="substring(//somedate,1,2)"> <!-- day-->
</xsl:apply-templates>

This assumes the date is in the form dd/mm/yyyy: the seperators could be different as they are ignored anyway based on the substring.

The important thing to realise here is that the <xsl:sort> functions do not do anything APART from sort, so there is nothing to see at this point if debugging

The work is done in a receiving

<xsl:template match="[match repeating datum]">
 
...
 
</xsl:template>

The ensures items are delivered to this block in the correct order, what is displayed is determined in the section

Now that we have Hello.Java created as a class.  Please refer to the blog
Creating a “Hello World” LiveSite Java External

I will demonstrate below how the class would be utilised in a LiveSite component.

- Create a component (name the component what ever you would like it to be)
- Select the component as XML/XSL format
- In Content XML, add the the following code;  

- Save the component, and Preview the Component
- You will see the Hello.Java class discussed in the blog
Creating a “Hello World” LiveSite Java External in your LiveSite component.

Java classes created in TeamSite & LiveSite reference many other Java files.  These files are located in a different directory of TeamSite, so are referred to as external files to the location where Java classes.

The problem with compiling a Java class comes when the Java file to be compiled looks for these reference files, but can’t find them as they are located externally to where a Java compile takes place.  This is not documented.

Solution:

1. Make sure the Java file you create is in the location;
iw-home/local/config/lib/content_center/livesite_customer_src/src

Files created should be placed into these location corresponding to the file type

iw-home/local/config/lib/content_center/livesite_customer_src/etc/conf for config files
iw-home/local/config/lib/content_center/livesite_customer_src/etc/web for jsp files

2. you need to copy the external jar files which you may require for your own Java file located in;
iw-home/httpd/webapps/content_center/WEB-INF/lib
to
iw-home/local/config/lib/content_center/livesite_customer_src/lib

There are many Jar files which have many java classes which might be referenced in your own Java file.  Typical Jar files which are recommended to copy to the location above are;
- dom4j-1.6.1.jar
- livesite.jar
- livesite_customer.jar
- livesite-runtime.jar

3. Once  you have copied these files over, in command line, navigate to
iw-home/local/config/lib/content_center/livesite_customer_src

4. Run the command iw-home/bin/make_toolkit.ipl

This should now build your Java file successfully to the Java class you require for your LiveSite external component

Thanks to Steve Russell from Realise for the below configurations for JCS Cache.

Here’s the properties you can set in JCS via cache.ccf in “./profiles/base/installedApps/nd_cellname/LiveSite Run Time.ear/iw-runtime.war/WEB-INF/classes/”…

JCS details here (http://jakarta.apache.org/jcs/getting_started/intro.html)

When copying over components from one environment to another, you loose the extended attribute which recognises the component as a Interwoven LiveSite component.  Below is how you would set the extended attribute, so that LiveSite recognises the component.

On command line or in a script you would need to execute the following;

iw-home/bin/iwextattr -s TeamSite/LiveSite/Type=component “hostname/iwadmin/main/livesite/component/WORKAREA/shared/component1”

or

cd iw-home/bin/
iwextattr -s TeamSite/LiveSite/Type=component “hostname/iwadmin/main/livesite/component/WORKAREA/shared/component1”

Note:

- For Solaris or Linux, if you get to iw-home/bin,  you would place ./ in front of iwextattr
- iw-home = TeamSite Install Directory
- hostname = Server/Host name
- /iwadmin/main/livesite/component/WORKAREA/shared/component1 = Example of a component stored in the shared workarea under components branch

From my experience there are a few things to bear in mind when installing Interwoven Software.  These include

1. Always install your software as administrator or full root (for solaris/Linux).  In respects to root access it must be full root not any sppof such as sudo. At the lease su root would be acceptable.  There have been installs where I have seen the installer not correctly installing, after which issues later arise.  Another reason to install as full root or administrator is that Interwoven will only support the software if they are installed by these users.
2. Always read the release notes, and ensure you fulfill the pre-requisites.
3. When selecting the install path, don’t leave any spaces.  I like to install as below;
   C:/Interwoven/TeamSite or C:/Interwoven/MediaBin
4. Keep a record of your actions whilst the install take place; will come in handy to document and to analyse any potential issues arising at a later date
5. Follow up your installation by executing any actions that are required after the install

Nested Quotations with XSL

It is not unusual to come across a situation where nested quotations fail (are exceeded) in an apperance XSL document.

Say I want to tie a Javascript function to an input control, but I want to pass the value of a datum-type as an argument to the funtion.

Therefore I want to describe an attribute value something of the order “JavaScript:handleJSFunction (’//Datum[@Name="someDatum"]‘);”

In practice this will fail as the nested quotes will not resolve (and CDATA will not work either, it will generate errors).

The solution is to take the theoretical expression:

<input type=”checkbox” name=”cb_boolean1″ value=”false” onClick=”JavaScript:handleJSFunction (’//Datum[@Name="someDatum"]‘);”/>

and break out the expression using <xsl:attribute/> tags, then using <xsl:text/> together with <xsl:value-of/> to concentatate the attribute string value with the required Datum value (s), thus avoiding interpolation errors::

            <input>
               <xsl:attribute name=”type”><xsl:text>checkbox</xsl:text></xsl:attribute>
               <xsl:attribute name=”name”><xsl:text>cb_boolean1</xsl:text></xsl:attribute>
               <xsl:attribute name=”value”><xsl:text>false</xsl:text></xsl:attribute>
               <xsl:attribute name=”onClick”>
                 <xsl:text>JavaScript:handleJSFunction(’</xsl:text>
                 <xsl:value-of select=”//Datum[@Name='someDatum']“/>
                 <xsl:text>’);</xsl:text>
               </xsl:attribute>

       </input>

If you get the below issue when trying to edit or view a page in LiveSite then check whether the server has run out of disk space:

“An error occurred while getting the page”

In the servlet_out.log file you may also see the following:

"Caused by: com.interwoven.livesite.common.business.BusinessException: Failed to get page //snt2k020/default/main/UK/WORKAREA/Content/sites/one/home.page
 
        at com.interwoven.livesite.business.BusinessPage.getTemplate(BusinessPage.java:771) 
        at com.interwoven.livesite.business.BusinessPage.getPage(BusinessPage.java:636) 
        at com.interwoven.livesite.business.BusinessPage.verifyChecksum(BusinessPage.java:188) 
        ... 40 more 
Caused by: java.io.EOFException 
        at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2228) 
        at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2694)

and in the /var/adm/eventsubd.log you may see the following

"Error: CRITICAL: page header magic for block 1 not OK 0"

The most likely cause is a problem with the /iw-home/eventsubsystem/openjms.db file.

Move this file to another area (it may be very large and have taken up 100% disk space under iw-home – you can check this by doing a ‘df -k’ command and looking at the results)

Also delete openjms.lock and openjms.lg in the same folder.

Re-start TeamSite and it should re-create this file (it may be the same size when you “ls -la” but on disk iw-home is no longer at 100%.

We think this is due to the service “reserving” the space that was previously used.)

If you want to reduce the amount of “claimed” disk space you should delete any “.0″ files under “/iw-home/loacl/logs/iwevents” folder and restart TeamSite (/etc/init.d/iw.server stop) and then (/etc/init.d/iw.server start).

Thansk to Mark Stradling for this tip, the below little template is useful to remove new lines using XSL:

<xsl:template name="removelines"> 
  <xsl:param name="text" /> 
  <xsl:value-of select="translate($text,'&#x0A','')" /> 
</xsl:template>