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

Re: Apply Templates, when to use which? how do templat

Subject: Re: Apply Templates, when to use which? how do templates work?
From: "John Smith" <debrief@xxxxxxxxx>
Date: Wed, 29 Aug 2007 16:21:29 +0100
Re:  Apply Templates
thanks Wendell, you made everything crystal clear.

On 8/28/07, Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> wrote:
> John,
>
> At 07:05 AM 8/28/2007, you wrote:
> >3. As there is also the "call-template" form of using a template, why
> >should one not always use that instead???, as it appears more easy to
> >understand in terms of the flow of the program.
>
> This is an excellent question, which you answer in the next sentence.
>
> >  I know xsl is not
> >executed like other "normal(imperative)" programming languages, but
> >when using apply-template I feel like I lose control of what is
> >happening when and in which order.
>
> Indeed, exactly right.
>
> XSLT is designed to allow a direct mapping from input to output. It
> is specified at a high enough (abstract enough) level to be
> implemented in different processors and environments that might (and
> commonly do) optimize the flow of control in their own ways. As a
> user you benefit in several important respects:
>
> * XSLT engines can be fast
> * The language is versatile, accomplishing all kinds of mapping tasks
> gracefully. What would make for very complex conditional processing
> is expressed elegantly through XPath selecting and matching.
> * The standard is tight enough to allow you to port easily from one
> engine or environment to another; so you can shop around for
> processors or use what's available.
> * Most important on a practical day-to-day basis: when coding, you
> can concentrate on mapping from input to output and let the flow of
> control take care of itself. As a consequence of template matching,
> XSLT is input-driven: the structure of the input determines the
> structure of the output, unless you specifically arrange otherwise.
>
> >4. What's the best practice for using applying templates in terms of
> >when to use which form??
> ><apply-templates />
>
> This is short for apply-templates select="child::node()". It selects
> the node children of the context node, and executes templates that
> match them, with each of the children used as context for its own match.
>
> >apply-templates select="xyz" />
>
> Short for select="child::xyz" (apply templates only to the 'xyz'
> element children of the context).
>
> ><apply-templates select="xyz" mode="foo" />
>
> Same, but in a mode.
>
> ><call-template name="bar" />
>
> Calling a template by name. In this case, the context does not change.
>
> >5. Is it possible to use apply-templates without the "select"
> >attribute but with a "mode" attribute???
>
> Yes, it's short for select="child::node()" mode="yourmode"
>
> >6. Is it possible to call-template where the template has a "match"
> >attribute as well??? If so how does it work? I mean, does it call the
> >template and the template checks for the match on the context node? or
> >do the call-template and the "match" apply at different times, as in
> >not both at the same time?
>
> Yes it is possible. If the template is called by name, it is invoked
> but the context does not change (it stays on the node that was being
> matched when the template was called). If the template is fired by
> virtue of matching a node that was selected by apply-templates, the
> context of evaluation of the template will be the selected node.
>
> I have left a lot out here. Presumably others are helping with more
> detail about what we mean by "evaluation context", and with an
> all-important feature of the language, the built-in templates that
> assure that at no time will a node be selected for template matching,
> without there being a template available to match it -- which
> provides for a built-in recursive descent.
>
> The archives of this list are chock-full of descriptions in one form
> or another of the XSLT Processing Model. Most books covering XSLT
> (and all the good ones) also describe it. When discussing XSLT with
> newcomers, we are rarely far from the subject, as it's both not
> obvious, but fairly simple and straightforward to grasp (assuming you
> bring no impediments to doing so) -- and extremely powerful.
>
> 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
> ======================================================================

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.