Re: [xsl] Apply Templates, when to use which? how do templates work?

["Dimitre Novatchev" <dnovatchev@xxxxxxxxx>]

See also:

   http://www.biglist.com/lists/xsl-list/archives/200411/msg00546.html


xsl:apply-templates is much richer and deeper than xsl:for-each, even
simply because we don't know what code will be applied on the nodes of
the selection -- in the general case this code will be different for
different nodes of the node-list. Also, the code that will be applied
can be written way after the xsl:apply templates was written and by
people that do not know the original author.


-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play



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
> ======================================================================