A brief history of the XSLT Mediator for SDL Tridion
Back in 2007/08, Tridion introduced a modular template framework called Compound Templates with R5.3. At the time you could use a combination of Template Building Blocks written in Dreamweaver (DWTs), C# Fragments and .NET assemblies to manipulate items in a package and add them to the output of your Compound Template.

This was a giant leap forward from what are now called legacy templates (VBScript, JScript and classic XSLT Component Templates) in SDL Tridion 2013. The concept of Compound Templates remains strong today, and is the primary way that developers render their content.

One of the key features of the template framework, was that it could be extended to support additional programming languages through the creation of Mediators. Over the years as developers got frustrated with the out-of-the-box mediators (C# Fragments, DWT and .NET assemblies), a number of community built Mediators have reared their heads, including ones for XSLT, Razor and Java.

I worked with Yoav and Frank back when R5.3 first came out to create the XSLT Mediator, which I have used on almost every project I have been on I the last 5 years. I rarely (if ever) use DWTs, and now have a library of XSLT templates which make up a large part of my toolbox to accelerate implementation. When SDL Tridion 2013 was released, one of the new features was an out-of-the-box XSLT mediator. I have been slowly modifying my accelerator templates to leverage this new functionality, which brings me to the reason for this blog.

Comparing the XSLT Mediators
In order to compare the Mediators, I recompiled the XSLT mediator from Tridion World to work with the new DLLs of Tridion 2013, and added it to the relevant configurations so I could run it side by side with the new XSLT Template Building Blocks. Below you can see a screenshot of these templates added to a Compound Component Template. Each TBB contains identical XSLT, and directly outputs a copy of the Component XML to an output object.

The first thing you will notice is the performance of the 2013 XSLT Mediator is drastically faster than the old community built XSLT Mediator. I didn’t do any detailed performance tests, because it was clear very early on that the new mediator was superior in terms of outright speed. Possibly one of the reasons for this is due to a modification I made to the community built one so that I could access Keyword URIs.

Loading Keywords with the XSLT Mediator
If you have ever done a project where you need to access values of a keyword (i.e. the key, description or metadata) that is used by a component with XSLT, you will most likely have come across this problem. The screenshot below shows the XML available to the XSLT mediator for the color field, where the keyword ‘Green’ has been selected. There is no way to know which category is used for this, or to access the keyword. In order to access additional information it is necessary to have the URI of the keyword.

Default XML loaded by the Community and 2013 XSLT Mediators

I added the following few lines of code to the Community XSLT Mediator which changes the default behavior so that the mediator loads the Component XML directly from Tridion (rather than getting it from the package). When it loads the Component it uses additional LoadFlags to add the Keyword URIs.

This results is the URI of the Keyword being added to the Component XML as you can see in the color field below.

This is clearly has a performance impact, as the Component is loaded twice (once by the framework to place the original Component into the Package, and then again every time the XSLT mediator is called. It would be far preferable for framework to use the LoadFlags when it first inserts the Component into the Package. I had hoped that this would be implemented along with the new XSLT Mediator with SDL Tridion 2013, but after closer inspection it is nothing to do with the Mediator.

I have added an enhancement request to ideas.sdltridion.com (please go and vote on it if you like the idea) to add these LoadFlags to the default component loader, but in the meantime the following 4 lines should do the trick.