/, LiveSite, XSL/XSL:Sort by Date, Organise by Type

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:


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.






By |2009-03-02T13:29:07+00:00March 2nd, 2009|Articles, LiveSite, XSL|0 Comments

About the Author: