XslExtensions be gone! – part 1

One of the features of Sitecore which challenges correct development practise is XslExtensions (or XslHelpers as we call them). Good examples of XslExtensions are the Sitecore.Xml.Xsl.XslHelper and Sitecore.Xml.Xsl.SqlHelper classes (read more here).

The possibility of hooking in your own .NET functions into your XSLT code is a vital part of Sitecore, but the concept of XslExtensions brings a few problems to the party:

  • XslExtensions are actually a return to the world of functional programming and removes the concept of which context your code is running.
  • XslExtensions are loosly bound to where it is used. In practise it is difficult to know from where your code is being called – if it is called at all.
  • Hooking in XslExtensions requires changes to your web.config file. This is actually not a big problem, but it would be nice to be without.
  • XslExtension methods require specific types as input and output. Therefore if you introduce nice functionality in a XslExtension method, it is bound to the XSLT compliant types.
  • XslExtensions lies on the border between the UI and the business logic tier of your application. Therefore XslExtensions can often be cluttered with methods which replicate and port functionality in your business logic to XSLT compliancy, or actually introduces new business logic functionality.

A good example of this last two points are Sitecore.Xml.Xsl.XslHelper.HasBaseTemplate() method, which is actually the only place in the Sitecore API where you can query whether an Item derives from a given template. This means that if you need this code in ASP.NET, you need to replicate the functionality in your own classes or – even worse – call Sitecore.Xml.Xsl.XslHelper.HasBaseTemplate() from your ASP.NET codebehind.

So, what can we do to try to enforce good development practise while still maintaining the essential functionality of exposing .NET methods to XSLT’s? I’ll get back to that in part two of my post.

~ by Eldblom on October 3, 2008.

Posted in Sitecore, XSL

3 Responses to “XslExtensions be gone! – part 1”

  1. In general XSLT is functional style coding. I’m also absolutely unhappy with . This is a casing unexpected side effect which are unexplaining as well. You cannot call it a monad as the behaviour can’t be described.
    I’ve talked about this with Ole and the reason to introduce this is that we’re not here to provide purity to developers, but productivity. Nevertheless, you are right that it’s not fancy.

    Looking forward to your next post :) .

    - Alex

    Alex de Groot said this on October 3, 2008 at 14:33 | Reply

  2. [...] Molten Core http://www.gravatar.com/blavatar/1c7460a0a1c24eed57fdab5b9dd721fd?s=96&d=http://s.wordpress.com/i/buttonw-com.png Source: http://mcore.wordpress.com/2008/10/03/xslextensions-be-gone-part-1/ [...]

    Sitecore Fetch Squad » Blog Archive » XslExtensions be gone! - part 1 said this on December 29, 2008 at 12:50 | Reply

  3. [...] This module created by Thomas Eldblom from Pentia allows you to add code behind files to your XSLT files in the same way that you would an ASP.NET page. You can visit the project room here and to get a more thorough insight into why you need this module, you can start with the first of three blog post on the subject here. [...]

    Sitecore Shared source is growing « Sitecore Shared Source Weblog said this on March 5, 2009 at 13:57 | Reply

Leave a Reply