[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: nested templates?

Subject: Re: nested templates?
From: Alex Black <enigma@xxxxxxxxxxxxxxxx>
Date: Wed, 16 May 2001 14:54:57 -0700
black 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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.