Hi Daniel,

That's definitely a bug - it makes no sense to use CDATA for that (will probably be fixed with an update soon).

That said, you will have to find a way to do it - I've seen several topics in the forums where parsing CDATA was a problem. I'd suggest you search for one of them and see if someone (probably the mighty Lee Kelleher :-) created an extension to convert a CDATA Section to a nodeset.

Just so you know: There's no amount of XSLT 1.0 pokery-jiggery that'll make you do it. Must find an extension.

 /Chriztian

I figured I would have to use an extension.  I'll see what I can find until the bug is fixed.

Thanks!

Looks like it should work great.. I'll give it a go and let you know.

Worked like a charm.. THANK YOU.  Here is the final XSLT.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xsl:stylesheet [  <!ENTITY nbsp "&#x00A0;">]>
<xsl:stylesheet
  version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:msxml="urn:schemas-microsoft-com:xslt"
  xmlns:local="http://local"
  xmlns:umbraco.library="urn:umbraco.library">

  <msxml:script implements-prefix="local" language="C#">
    //<![CDATA[
    public XPathNodeIterator parse(string data) {
        if(data==null || data.Length==0) {
            data="&lt;Empty /&gt;";
        }
        System.IO.StringReader stringReader = new  System.IO.StringReader(data);
        XPathDocument xPathDocument = new XPathDocument(stringReader);
        XPathNavigator xPathNavigator = xPathDocument.CreateNavigator();
        XPathExpression xPathExpression = xPathNavigator.Compile("/");
        XPathNodeIterator xPathNodeIterator = xPathNavigator.Select(xPathExpression);
        return xPathNodeIterator;
    }
    //]]>
  </msxml:script>

  <xsl:output method="xml" omit-xml-declaration="yes"/>

  <xsl:param name="currentPage"/>
    
  <xsl:template match="/">
  
    <xsl:variable name="nodes" select="local:parse($currentPage/ancestor-or-self::* [headerNodes != ''] [1] /headerNodes)"/>
    <ul>
      <xsl:for-each select="$nodes/MultiNodePicker/nodeId">
        <li>
          <xsl:if test="position() = 1">
            <xsl:attribute name="class">first</xsl:attribute>
          </xsl:if>
          <a>
            <xsl:attribute name="href">
              <xsl:value-of select="umbraco.library:NiceUrl(.)"/>
            </xsl:attribute>
            <xsl:value-of select="umbraco.library:GetXmlNodeById(.)/@nodeName"/>
          </a>
        </li>
      </xsl:for-each>
    </ul>
    </xsl:template>
</xsl:stylesheet>

Just had this issue as well. I thought it had been fixed, as I couldn't see the CDATA in the XML i wrote out from a copy-of in a textarea. But I couldn't figure out why my iteration through the selected node id's didn't work. So I took a look in the database, and here I also saw the CDATA. But I gues it'll be fixed in the future versions of this great datatype :)

Actually I just wanted to say thanks for the code snippet guys ;)

/Kim A

Daniel, glad you got it resolved. I'll speak to Shannon about the CDATA issue (when he gets back from holiday).

As for the C# snippet in your XSLT - I wouldn't recommend doing it that way - there are major performance issues by doing that.  Each time the page is loaded, the code is executed at runtime and stored as a file in the "Temporary ASP.NET Files" folder - so depending on the traffic of your website, it could start to fill up your disk-space quite quickly.

The better approach is to move the snippet to its own DLL and reference it as an XSLT extension.

Cheers, Lee.

I'll do that now.. don't want to have issues later down the line.. Thanks!

You're welcome.  I used to use inline C# code in my XSLTs all the time, until Benjamin Howarth told me about the Temp ASP.NET folder - which he found out during his Medium Trust development - also that inline XSLT code doesn't work in Medium Trust - that's Full Trust only!

Anyway, you live and learn! :-D

Cheers, Lee.

is working on a reply...