look like priority attribute can help in some cases - you can give
higher priority for frequent cases and lower priority for rare cases
i think in many cases power of using tunnel variables and next-match
underestimated by developers too
in many cases using other mode (even if it not necessary by logic)
help for speed also
2012/11/4 Daniel Sullivan <dsullivan(_at_)danal(_dot_)com>:
I agree doing code in smaller pieces is usually better. I was just following
Ken's terms of declarative and imperative to refer to things the same way he
was.
But in XSLT you can, in effect override a part of a monolithic method, i.e.
template.
If the importing stylesheet has something like:
<template match="thenode[child::x]">
... do_this ...
</template>
And the imported stylesheet has something like:
<template match="thenode">
<xsl:choose>
<xsl:when test="x">
... do_this ...
</xsl:when>
<xsl:otherwise>
... do_that ...
</xsl:otherwise>
</xsl:choose>
</template>
Then when the xml being processed has an <thenode><x/></thenode>, thenode
will be processed by the importing stylesheet.
And a node like <thenode><a/></thenode> will be processed by the imported
stylesheet.
So you can override parts of a monolithic template.
I'm not saying it's a good thing to do, just that it is a very handy
technique when you have to use a stylesheet that you are not allowed to
change.
Dan
-----Original Message-----
From: Michael Kay [mailto:mike(_at_)saxonica(_dot_)com]
Sent: Saturday, November 03, 2012 4:04 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] Perfomance: 'conditional instruction' vs. 'multi template'
On 03/11/2012 18:42, Daniel Sullivan wrote:
But templates in the importing stylesheet that match have absolute priority
over those in the imported stylesheet, so a declarative stylesheet that
imports another stylesheet would have the same effect whether the imported
stylesheet was declarative or imperative, wouldn't it?
The point is that if you split your code into smaller templates, then you can
override smaller parts of your code. It's the same as in OO programming - big
monolithic methods can only be overridden in-toto, you can't change parts of
their behaviour selectively.
Incidentally, the terms "declarative" and "imperative" for describing this
distinction are not really very appropriate. Arguably everything in XSLT is
declarative. It's just that some constructs look more imperative than others
- especially those like choose and apply-templates and format-number that are
expressed using imperative English verbs.
Michael Kay
Saxonica
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--