xsl-list
[Top] [All Lists]

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

2007-08-29 15:23:46
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(_at_)mulberrytech(_dot_)com> 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(_at_)mulberrytech(_dot_)com
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
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--