Friday, February 5, 2010


Presentation controls are an important part of Sitecore's strategy for displaying content. When these controls are created using .NET they are either sublayouts or web controls. When these controls are created using XSLT then are called "renderings"

Renderings serve the same purpose as any other presentation control (they provide blocks of reusable presentation logic). They are configured in the same way (they consist of a definition item as well as a physical file). They are developed and deployed similarly (changes to the files the definition items point to can be changed and deployed without having to notify Sitecore).

The idea with renderings is that Sitecore provides a view of itself in an XML structure, which can be transformed into HTML (or whatever presentation format you want) using XSLT.

Sample of the XML representation of a Sitecore item.

XSL extension methods are used to display field values in renderings. Placeholders cannot be defined in renderings.

One of the nice features available to you when using renderings is the Sitecore Developer Center. This is a part of the Sitecore user interface where developers are able to work on and debug their code. The Developer Center includes a preview screen that allows you to watch your XSLT execute as you write it.

Changes to XSLT files can be previewed inside Sitecore.

XSLT or not?
Using XSLT in Sitecore is something that people tend to feel passionate about. I've heard the arguments (some of them, anyway), but there are 2 things that make me feel that - as a general rule - it's probably better to stay away from XSLT.

First, .NET code runs much faster than XSLT code in Sitecore. Some people argue that the proper use of Sitecore's caching features renders this a moot point. I don't know enough about how Sitecore caching works to know how many situations this holds true for. I know from working with other system that there are times when content just can't be cached. For example, personalized navigation.

My second issue involves code maintenance. Trying to understand someone else's code is seldom a pleasant task, but trying to understand someone else's XSLT code takes unpleasant to another level. With .NET code you have Visual Studio to help you in a variety of ways. I'm not aware of any way to debug XSLT code running in Sitecore. Sure, it might take 1/2 the time for you to write XSLT code, but I wonder if that efficiency evaporates when it's time for someone else to work with the code.

Still, it is important to note that renderings are not a gratuitous or deprecated feature. There are places they are genuinely useful. In cases where you need to traverse multiple levels of the content tree (building navigation links, for example), using XSLT is a fast and powerful tool.

What's next?
Now that we've seen how controls are created, the next thing to cover is how are they used. My next post will cover this topic.

Want to learn more?

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.