Kevin, interesting take – but I tend to stand on the other side of that particular fence. For me, template matching is the most beautiful concept in XSLT. It’s the default behaviour by design, I can never understand why anyone would want to tamper with it by littering their stylesheet with < xsl:for-each > and called templates when there’s no good reason to do so, although I see it all the time. There’s nothing more elegant to me than being able to match the root node, apply templates and just pick out what you need by matching, not that it’s ever that simple in the real world alas.
XSLT is immensely powerful, but if I found myself regularly attempting to replicate traditional programming concepts within it I’d start to question why I wasn’t using a traditional programming language in the first place.
Ian, nice article, it’s a subject that doesn’t come up often enough. I do have one issue though: Within the template matching the category element, the context node is a single instance of a category element. The < xsl:for-each select=”.” > is therefore redundant as it will only ever match one category element – the current one. This template is already invoked independently for each category since you used < xsl:apply-templates select=“atom:category” > in the entry template, the < xsl:for-each > adds nothing but a slight processing overhead to each pass.
Will Prescott
Kevin, interesting take – but I tend to stand on the other side of that particular fence. For me, template matching is the most beautiful concept in XSLT. It’s the default behaviour by design, I can never understand why anyone would want to tamper with it by littering their stylesheet with < xsl:for-each > and called templates when there’s no good reason to do so, although I see it all the time. There’s nothing more elegant to me than being able to match the root node, apply templates and just pick out what you need by matching, not that it’s ever that simple in the real world alas.
XSLT is immensely powerful, but if I found myself regularly attempting to replicate traditional programming concepts within it I’d start to question why I wasn’t using a traditional programming language in the first place.
Ian, nice article, it’s a subject that doesn’t come up often enough. I do have one issue though: Within the template matching the category element, the context node is a single instance of a category element. The < xsl:for-each select=”.” > is therefore redundant as it will only ever match one category element – the current one. This template is already invoked independently for each category since you used < xsl:apply-templates select=“atom:category” > in the entry template, the < xsl:for-each > adds nothing but a slight processing overhead to each pass.