This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Re: Re: Increment/decrement a variable in XSL
You have, however, good points. My experience with those ugly
side-effects is based on one processor only, whose internals I know in
detail. Since funct:script/xsl:script isn't supported by common
processors yet, the portability hasn't been a practical issue. I roll
back my suggestion as an alternative XSLT solution, this is more likely
a proprietary optimization outside of the area of interest of this list.
Have a nice day,
Petr
Jeni Tennison wrote:
>
>Dimitre's absolutely right. Being able to bug out to a different
>programming language can be really useful because they have support
>for things that XPath/XSLT doesn't support (e.g. regular expressions)
>or because they have access to system information that XPath doesn't
>have access to (e.g. the current date and time; file listings).
>func:script (and xsl:script in the XSLT 1.1 WD, on which it's based)
>give a standard way of referring to implementations of extension
>functions in other programming languages for these kinds of tasks.
>
>However, it's very dangerous to use extension functions or extension
>elements that have side-effects in XSLT, such as counters or
>extensions that read and update databases. This is because XSLT is
>designed around the basic assumption that you can evaluate the same
>expression multiple times without affecting the result of that or
>other expressions.
>
>Imagine you had a simple function:
>
><func:script language="javascript" implements-prefix="my">
> var count = 0;
> function increment() {
> count++;
> return count;
> }
></func:script>
>
>And that in your XSLT you had:
>
> <xsl:variable name="count" select="my:increment()" />
> <xsl:value-of select="$count" />
> <xsl:value-of select="$count + 1" />
>
>As XSLT is designed, a processor is free to evaluate the expression
>"my:increment()" once, five times, ten times, 100 times if it wants.
>Realistically, a processor might evaluate it once (to assign the
>result to $count, which is then used in the two xsl:value-of
>instructions) or it might evaluate it twice (once for each of the
>xsl:value-of instructions in which the $count variable is referenced)
>if it thinks that storing the variable is going to be more costly than
>evaluating it twice. If it did the latter, then rather than getting
>"1" and "2", you'd get "1" and "3".
>
>Equally, if you had:
>
> <xsl:value-of select="my:increment()" />
> <xsl:value-of select="my:increment()" />
>
>a processor is free to evaluate the function call my:increment() as
>many times as it likes. It might evaluate it twice (once for each
>xsl:value-of instruction) or it might evaluate it once (detecting that
>the same expression was used in both places and that therefore it can
>use the same value) if it thinks that storing the value is going to be
>less costly than evaluating it twice. If it does the latter, then
>rather than getting "1" and "2", you'd get "1" and "1".
>
>In other words, the assumption that nothing in XSLT produces side
>effects enables XSLT processors to make all sorts of useful
>optimisations. If you use an extension that does have side effects,
>and your processor performs these optimisations, then you will run
>into problems.
>
>Cheers,
>
>Jeni
>
>---
>Jeni Tennison
>http://www.jenitennison.com/
>
>
> XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
>
--
Petr Cimprich
Ginger Alliance
www.gingerall.com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list