RE: [xsl] nested templates?

Subject: RE: [xsl] nested templates?
From: "Chris Bayes" <Chris@xxxxxxxxxxx>
Date: Wed, 16 May 2001 21:53:58 +0100
Wendell,
Because <xsl:template match="bookmark"> will apply for all bookmarks
anywhere and not just below the templates they are in. Which I think is the
point! It's a scoping issue.

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 Wendell Piez
>Sent: 16 May 2001 16:30
>To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
>Subject: Re: [xsl] nested templates?
>
>
>Alex,
>
>At 08:58 PM 5/16/01, you wrote:
>>below is a real world example of for-each. (first 'document')
>>this works.
>>
>>which is fine, but I far prefer nested templates, because that
>implies that
>>I can _import_ those templates wherever I like, and build up complex
>>documents out of little sub-formatters.
>
>I'm puzzled. Why can't a template that's not nested match just fine, be
>'imported' just fine, whenever you need it?
>
>So
><xsl:template match="/">
>   <xsl:apply-templates/>
></xsl:template>
>
><xsl:template match="bookmark">
>   <output>
>     <xsl:apply-templates/>
>   </output>
></xsl:template>
>
>The second template will match *any* bookmark element that happens to be
>picked up by an apply-templates instruction, it doesn't matter
>where in the
>tree, how deep, or how many times: it always works the same way. All you
>need to do is make sure that your xsl:apply-templates call it properly
>(which is one reason why the built-in defaults provide for a depth-first
>traversal covering every node). Isn't that exactly what you want?
>
>>I'm warming up to this language rapidly, after you get over the amazing
>>verbosity of the syntax, it works quite well, actually :)
>
>If I'm right and you just haven't 'clicked' with the processing model (and
>to be sure, alot is under the surface and you have to learn it's there
>before you can properly see why things work the way they do), you'll soon
>like it even better.
>
>Or to put it in a nutshell, it's not XSLT that's the problem, it's our
>misplaced assumptions, typically drawn from other programming paradigms,
>that are getting in the way.
>
>Sorry I can't help with the Sablotron stuff.
>
>Cheers,
>Wendell
>
>
>======================================================================
>Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
>Mulberry Technologies, Inc.                http://www.mulberrytech.com
>17 West Jefferson Street                    Direct Phone: 301/315-9635
>Suite 207                                          Phone: 301/315-9631
>Rockville, MD  20850                                 Fax: 301/315-8285
>----------------------------------------------------------------------
>   Mulberry Technologies: A Consultancy Specializing in SGML and XML
>======================================================================
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>


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


Current Thread