Re: nested templates?
hi tom, thanks - xsl:call-template is essentially what I was looking for re: "element handlers" I must disagree strongly with the idea that XSLT should be OO, it is specifically for building complex, nested _hierarchies_ - thus my post. Some examples from other posts: (as I have apparently started a fire) > Why not? A template matches a node, matching it by node type, by element or > attribute type name, or by some other identifier such as an ID or key > value. It doesn't matter where in the source tree the node is, or how deep; > once that node is picked up for processing (through an xsl:apply-templates > instruction), the template applies. For a given type of node, you get a That's fine if you're dealing only with arbitrary nodes, which in _some_ cases is exactly what I want to be able to do. xsl:call-template is perfect for those cases, as far as I'm concerned. however, in many other cases I need to have a complete, editable picture of the hierarchy of a document I'm creating. the lots-of-little-bits-way doesn't give me that. I've used nearly every kind of template system on earth, and I have found that I work much faster if I can mix "objects" (i.e. xsl:call-template for a "bookmark" in the example I gave) and "documents" (large nested hierarchies, consisting mostly of layout code) > given output. Why is this not useful? It seems particularly elegant and > powerful especially for the sort of semi-structured, > not-entirely-predictable, arbitrarily deep, hierarchical data sets > (documents) that are so common among markup applications. Many of us use it > every day. Above, I have nothing against templates that do that, but I see no reason to _prevent_ users from nesting templates. I'm not suggesting that you should _have_ to nest your templates, I think it should be something that XSLT can do. > Since you used the magic word "goto", I think that the lack of structure is > what is conceptually wrong with the original idea of "nested templates(from > Alex Black) in the first place. This is like the (legal) COBOL structure This is confusing, as I am implying that I would like a more deeply nested structure that is currently doable with xslt. I want _more_ structure, not _less_ structure. > of PERFORM paragraphs A THRU K, and then having other places where you just > PERFORM B (which was in the original sequence A THRU K). This leads to > unmaintainable spagetti code in a big hurry. I think this is why Wendell > Piez and Tom Passin were urging the "lots of little bits" approach. In > fact, Wendell was quite explicit about this (though he may not appreciate > my "help" here). Right, which is why you should be able to do both, and mix them as you see fit. But I really can't come up with a good reason why it should be _illegal_ syntax to nest <xsl:template> elements. _alex -- alex black, ceo enigma@xxxxxxxxxxxxxxxx the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format