extending the org.apache.xalan.extensions.ExtensionHandlerJavaClass

[Adrian Herscu <bm...@fastmail.fm>]

Hi all,

I am trying to enhance the readability of my XSL code.
One of the options is to reduce things like named template calls to 
function calls; for example:

<xsl:variable name="foo">
   <xsl:call-template name="getFooFrom">
     <xsl:with-param name="moo" select="$moo" />
   </xsl:call-template>
</xsl:variable>

can be reduced to:

<xsl:variable name="foo" select="my:getFooFrom($moo)" />

which is shorter and more readable.

However this requires the re-implementation of each named template in 
Java. I would like to find a way to make it work without providing Java 
implementations. Hence I am looking to override the 
ExtensionHandlerJavaClass::callFunction() method in order to make it 
check whether there is a 'getFooFrom' template and call it as it would 
be called by an xsl:call-template. What I have found so far is that the 
ExtensionHandlerJavaClass is hardcoded in the ExtensionNamespacesManager 
class :( Do I miss something?

Adrian.

Re: extending the org.apache.xalan.extensions.ExtensionHandlerJavaClass

[ke...@us.ibm.com]

I can't remember whether we already mentioned that you can capture a 
template's results into a variable, which can also help avoid extensions:

        <xsl:variable name="foo">
                <xsl:apply-template ...>
        </xsl:variable>

Of course that doesn't return the original nodes, just the result 
generated by the template. And in XSLT 1.0, if you want to further process 
the result you'll need to use the exslt nodeset function to make the 
Result Tree Fragment accessible that way. But this, combined with named 
templates, can sometimes be persuaded to substitute for things you'd 
otherwise need an extension for.

______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
  -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (
http://www.ovff.org/pegasus/songs/threes-rev-11.html)

Re: extending the org.apache.xalan.extensions.ExtensionHandlerJavaClass

[Adrian Herscu <bm...@fastmail.fm>]

keshlam@us.ibm.com wrote:
> The implementation details of calling a template are significantly 
> different from those of calling an external function. I don't think you're 
> going to be able to make this work easily.
> 
> Suggestion: Can you rewrite the template you want to invoke as an XPath? 
> If so, you could use that directly in the variable's select field. 

This works well if the XPath expression is short enough. For example:
concat('services.',string:lowerCase(@name))

The downside is that you loose the semantics...

Thanks anyway,
Adrian.

Re: extending the org.apache.xalan.extensions.ExtensionHandlerJavaClass

[ke...@us.ibm.com]

The implementation details of calling a template are significantly 
different from those of calling an external function. I don't think you're 
going to be able to make this work easily.

Suggestion: Can you rewrite the template you want to invoke as an XPath? 
If so, you could use that directly in the variable's select field. 

XSLT 2.0 does add the ability to write named functions in XSLT and invoke 
them from within XPaths. Unfortunately, Xalan only supports XSLT 1.0.

______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."
  -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (
http://www.ovff.org/pegasus/songs/threes-rev-11.html)