Most methods in XslHelper are virtual, so it's possible to tweak the output of sc:something() functions and <sc:something /> controls in XSL renderings. To change the behaviour of all renderings in Sitecore solution, modify the sc xsl extension registration in web.config:

<xslExtensions>
  <extension mode="on" type="Sitecore.Xml.Xsl.XslHelper, Sitecore.Kernel" namespace="http://www.sitecore.net/sc" singleInstance="true" />
  <extension mode="on" type="MyNamespace.MyClassDerivedFromXslHelper, MyAssembly" namespace="http://www.sitecore.net/sc" singleInstance="true" />

To use the derived extension selectively, just register it as a new xsl extension.

Note that it's a fairly crude hack probably involving some string manipulation, but as such it can also help when other methods fail.

Sitecore has two kinds of item XML representation, or flavors if you will.

Serializer XML is the heavyweight format, containing everything Sitecore needs to know to get the item from one solution and paste into other: all attributes, field values in all versions and languages. It is used by the packager.

To get serializer xml programmatically:

item.GetOuterXml(deep);

XSLT XML is the internal interpretation that is fed to XSL renderings (tranformations). This is the lightweight brother, containing only item attributes and field ids. No field values, only the current version and language. You would want to know how it looks like if you code XSL renderings.

To get XSLT xml programmatically:

ItemNavigator navigator = Factory.CreateItemNavigator(rootItem);
writer.Write(navigator.OuterXml);

In the next (3.0.13, soon to be released) version of demo site, we have added the option to output item XML in both flavors to demonstrate what it feels like:

http://<demositeurl>/?xml=    => Serializer XML flavor of the current item (no children)
http://<demositeurl>/?xml=&deep=true    => Serializer XML flavor of the current item and all descendants
http://<demositeurl>/?xml=&xslt=true    => XSLT XML flavor of the current item and all descendants (always 'deep')

Thanks to John West for the idea.

It's a bad practice for a page to link to itself, unless its an anchor. It is a small difference, but it's all about the details, isn't it?

Preferably, both markup and visual appearance should be different. For demosite, it means:

instead of

instead of

(although I don't think the site needs a third link home anyway)

instead of

In xslt, it's as simple as a check for "@sc_currentitem/@id = @id" or "@sc_currentitem/@id = sc:GetLinkItem(...)/@id".

Below is the difference between xslt of vertical menu (the most complex of 3 changes). Before:

<a href="{sc:path(.)}" class="text_2">
  <!-- link content we don't want to duplicate -->
</a>

After:

<xsl:variable name="tagname">
  <xsl:choose>
    <xsl:when test="@id = $sc_currentitem/@id">span</xsl:when>
    <xsl:otherwise>a</xsl:otherwise>
  </xsl:choose>
</xsl:variable>

<xsl:element name="{$tagname}">
  <xsl:attribute name="href"><xsl:value-of select="sc:path(.)" /></xsl:attribute>
  <xsl:attribute name="class">text_2</xsl:attribute>

  <!-- link content we don't want to duplicate -->
</xsl:element>

Wouldn't it be nice if <sc:link /> could handle it by itself? It is a breaking change, unfortunately.

One of the downsides of XSL extensions is that an entire Sitecore solution needs to be restarted both when a new extension is registered (web.config change) and existing extension is modified (recompilation). Compilation itself can also be a burden. Plain XSLTs, in contrary, are easy to modify, and the result is immediately visible on the website.

Dynamic extension compilation is an attempt to solve this and make extensions more viable. It will compile and register all extensions in /App_XslExtensions (configurable) folder in Sitecore root both when Sitecore starts, and when extension is created or updated.

Below is the example of such extension file:

using Sitecore.DynamicXslExtensions.Attributes;
namespace Sitecore.DynamicXslExtensions.Tests
{
   [XslExtension("http://www.sitecore.net/testnamespace")]
   public class TestExtension
   {
      public string helloWorld()
      {
         return "Hello, World!"
      }
   }
}

If the file is placed inside the /App_XslExtensions folder, it will be compiled automatically, and you can register the http://www.sitecore.net/testnamespace extension as usual. What is not usual is that you can tweak the helloWorld() method in any file editor (or using Sitecore IDE) and see the changes live on the website.

Underlying process is similar to how Sitecore compiles XML controls. And just as in XML control code, you can modify a list of assembly references during automatic compilation using ui/references section of web.config.

Installation is as simple as I could make it: install the package, and add
<processor type="Sitecore.DynamicXslExtensions.Loader, Sitecore.DynamicXslExtensions" />
to pipelines/initialize in web.config.

Download Package.