Feb. 3, 2011, 4:55 p.m.
posted by dio
Recursive Versus Iterative Style Sheets
One of the things about XSLT is that although the capability exists for iteration (looping), it is strongly frowned upon by the development community. Instead, recursive templates are considered the acceptable standard. Although this philosophy requires some changes in the way developers think, it also means that recursive style sheets are often far more compact and not nested nearly as deep as their iterative counterparts. At the very least, recursive style sheets are always far more structured, which can be a major advantage in larger style sheets.
Let's say that our goal is to create an XSLT table and the source XML document shown in Listing 10-2. As a starting point, there are two distinct courses of action: an iterative style sheet (see Listing 10-3) and a recursive style sheet (see Listing 10-4). Each of these two approaches to coding style sheets has its own strengths and weaknesses. For example, the iterative style sheet is about the same length, but it is also nested much deeper than the recursive style sheet.
-2. Source XML Document
-3. Iterative Style Sheet
-4. Recursive Style Sheet
The decision to use an iterative design or a recursive design is more a matter of personal taste and comfort than any rule imposed from on high. For example, many developers new to XSLT start by writing iterative style sheets and move to recursive methods only when they become more confident in their abilities. But in the end, the result of the two style sheets is the same as shown in Listing 10-5.
Listing 10-5. Result from Applying Either Style Sheet to the XML in Listing 10-2
If you're in a cubical right now, take a moment and look around; you're the absolute ruler of all that you survey. The desk and its contents all fall under your benevolent influence, as do the coffee cup and its contents. However, all that is beyond the imaginary line that separates your cubical from the corridor is beyond the scope of your influence and belongs to another. This simplistic description of office life is essentially the same as how the concept of scope works in XSLT. In XSLT, scope is applied to both the context node, the current position in the XML document, and the variables.
It is best to think of scope along the same lines as local and global variables in other programming languages. For example, if a variable is defined within an if statement, it is accessible only inside that if statement. Or if a variable is defined within a function (template in XSLT), it can be used only within that function, not in any subsequent function, unless it is passed as a parameter. Variables defined on the root level are considered global to the entire XSLT document. Also, while we're on the subject of variables, I should describe the toughest issue that new developers have with learning XSLT.
This, probably more than any other aspect of XSLT, has caused more developers to run screaming into the night, although I'm not sure, having never conducted any research into the subject. After all, how long can you develop without Jonesing for a fixer, make that needing a way to alter a variable or something along those lines?
There is, however, a way around this issue; remember what I said about scope? That scope can be both local and global? Imagine, if you will, a recursive template. Yes, the headaches are starting already, but bear with me on this. There is absolutely no reason why a template cannot call itself. Okay, that's really useful information. A template can get around this issue, and it would be even more useful if I were to explain what a template is.