This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
XSLT eval()
- To: "'xsl-list at mulberrytech dot com'" <xsl-list at mulberrytech dot com>
- Subject: XSLT eval()
- From: John Lam <jlam at iunknown dot com>
- Date: Sun, 20 Feb 2000 17:19:21 -0500
- Reply-To: xsl-list at mulberrytech dot com
As the archives aren't available, I don't know if this issue has been
discussed already on this list, so my apologies if this is the case ...
Have there been discussions with regard to adding the equivalent of the
JavaScript eval() function to XSLT / XPath as either a core function or as
an add-on extension function?
There are cases where one would really like to have some parameterized
evaluation, the case of <xsl:sort> comes to mind virtually right away.
Consider this XSLT frag:
<xsl:param name="COLUMN select="name"/>
...
<xsl:for-each select="item">
<xsl:sort select="$COLUMN"/>
...
It doesn't evaluate to what you would want to since $COLUMN is not evaluated
to return a node-set at run-time. Instead the string expression of $COLUMN
(e.g. "name") is inserted into the select attribute at run-time.
Instead, if we could write:
<xsl:param name="COLUMN select="name"/>
...
<xsl:for-each select="item">
<xsl:sort select="extensionFunctionNamespace:eval( $COLUMN )"/>
...
this would provide the best of both worlds, no? And shouldn't this be
relatively straightforward to add to one of the existing XSLT
implementations assuming that it has a fairly modular XPath implementation?
Or is there something that I'm missing here?
Regards,
-John
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list