Rick,
No it isn't. It is a more objective aproach. This object/template has a
method "transform" on these children if they exist. I'm not talking about
goto/call-template at some point in the tree.
I don't think it should lead to spagetti code any more than objective code
does over procedural code. It should reduce it because some templates are in
their place (withinn a template) rather than strung out over the length of
the code.
I know it isn't but as it stands xsl templates do look like a bit like the
old basic goto code of years ago. The flatness of it almost lends itself to
line numbers.

Don't get me wrong. I'm not arguing for any change. I just think sometimes
"sheesh nested templates would be nice at this point"
I just thought we should talk about it a bit. Nothing better to do.

Ciao Chris

XML/XSL Portal
http://www.bayes.co.uk/xml


>-----Original Message-----
>From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx
>[mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of
>RSuiter@xxxxxxxxx
>Sent: 16 May 2001 22:08
>To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
>Subject: RE:  nested templates?
>
>
>
>Chris Bayes:
>
>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
>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).
>
>Rick Suiter
>
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list