Symphony.

Hello, I'm following the tutorial on xslt on tizag. But I can't match any "element" in the xml file just by tiping element in the symphony debug window. I need to enter *//element**

Correction: I can match "homepage-articles" with homepage-articles, but not "homepage-articles/entry" with entry.

How come? Thanks!

Presumably because element only matches a child and //element matches any descendant.

A child is an element nested within the context node, i.e.

<parent>
    <child />
</parent>

while a descendant may also be a child of a child, i.e.

<parent>
    <child-or-descendant>
        <descendant>
            <descendant />
        </descendant>
    </child-or-descendant>
</parent>

All Xpath-expressions are also bound to a so-called context node: depending on your context, the very same xpath expression will yield different results.

In the case of that (slighly dumb) xpath interpreter in the debug view, the context is always the root node.

This means: the only child-expression that would work in that interpreter would be data as it's the only child to the root node. To match any other node within the tree you'd have to address it like data/data-source/entry/element or simply //element, in wich case you lose the ability to address only elements within a certain Data Source.

Thanks Phoque for your reply.

Looks like the parser is not following the xpath specification. Are there other non-standard issues in the cms adoption?

I was trying to explain that it is following the specification, you're simply not able to set a context node.

That parser there is indeed an exception though, as it's implemented in JavaScript. The actual XSLT transformations are done on the Server by libxsl, not by anything custom-made. Meaning: Everything else in Symphony is as standard-conform as libxsl's implementation.

Yes Phoque you are right, this tizag's page is just telling that to match "inventory/drink/lemonade/amount" you have just to enter amount, I wonder why...

That's the concept of context nodes.

For example these two expressions are equal:

<xsl:template match="/">
    <xsl:value-of select="inventory/drinks/lemonade/amount"/>
</xsl:template>

In this example you are in the root node /, the element you're looking for is the child of the child of the child of your child.

<xsl:template match="inventory/drinks/lemonade">
    <xsl:value-of select="amount"/>
</xsl:template>

In this example you are already "inside inventory/drinks/lemonade", the element you're looking for is your own child.

Another example are for-eaches:

To access one of the nodes of the ones you're looping over you only need a relative expression:

<xsl:for-each select="inventory/drinks/limonade">
    <xsl:value-of select="amount"/>
</xsl:for-each>

You're iterating over all elements of type lemonade and are printing out the value of their child, amount.

The alternative, an absolute expression doesn't make sense because it's not clear which element of type lemonade you mean.

<xsl:for-each select="inventory/drinks/limonade">
    <xsl:value-of select="inventory/drinks/limonade/amount"/>
</xsl:for-each>

That concept is very important and integral to XSLT and the fact that this xpath parser in the ?debug view doesn't support it is the main reason why almost nobody is using it. :-)