This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: nested templates?
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: Re: [xsl] nested templates?
- From: Alex Black <enigma at turingstudio dot com>
- Date: Wed, 16 May 2001 14:54:57 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
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@turingstudio.com
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