Re: [xsl] nested templates?

[Alex Black <enigma@xxxxxxxxxxxxxxxx>]

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