4 ms·
Most people who encountered it never really understood its programming model. In short, they tried to use it as an imperative language, but XSLT doesn't want to
by dionidium 5y ago
Most people who encountered it never really understood its programming model. In short, they tried to use it as an imperative language, but XSLT doesn't want to be an imperative language. The basic paradigm is pattern matching. You're supposed to create templates that say what to do when a node meeting certain characteristics is encountered (including how/whether to continue descending into the node's children/siblings/etc). Instead, what you see in most real-life XSLT programs is a whole bunch of xsl:if statements that attempt to conditionally (and, worse, procedurally) handle multiple node types within a single template. That's a dead giveaway that the program's author didn't really understand what they were trying to do or how to accomplish it in the language.
XSLT doesn't do itself many favors, either, because the model depends on the execution of a few "hidden" default templates that drive the tree processing. If you don't know those are there or what they're doing -- or worse, if you don't know they're there and you accidentally override them -- then it's really hard to understand what the heck is going on. It just looks like poorly-defined magic.
Plus, you need to understand XPath to write effective templates and most people don't understand it as well as they think they do. It's deceptively powerful.
Finally, add on the fact that XSLT programs are themselves valid XML -- who the heck wants to write code in XML! -- and it really never had a chance to be understood, much less liked.
But many of its ideas were good!
- leephillips 5y agoThis describes my one serious attempt to use XSLT pretty well. It seemed like a powerful idea. But after some weeks of struggling with it, I decided the syntax was too painful to deal with. But I know I never learned it properly, as you say.