<xsl:apply-templates select="
//jpath:if [generate-id(.) = generate-id(key('JPathExprs', @test))]
| //jpath:when [generate-id(.) = generate-id(key('JPathExprs', @test))]
| //jpath:value-of[generate-id(.) = generate-id(key('JPathExprs', @select))]
| //jpath:for-each[generate-id(.) = generate-id(key('JPathExprs', @select))]"
mode="compile"/>
instead of
<xsl:apply-templates select="
(//jpath:if | //jpath:when)
[generate-id(.) = generate-id(key('JPathExprs', @test)[1])]
| (//jpath:for-each | //jpath:value-of)
[generate-id(.) = generate-id(key('JPathExprs', @select)[1])]"
mode="compile"/>
So you can at least get it to run with the current Xalan/XSLTC.
Regards,
Joerg
Joerg Heinicke wrote:
1. The differences between Cocoon and command line result from the usage of XSLTC in Cocoon.
2. Further investigations with Xalan (not XSLTC):
<xsl:key name="JPathExprs" match="jpath:if" use="@test"/>
<xsl:key name="JPathExprs" match="jpath:when" use="@test"/>
<xsl:key name="JPathExprs" match="jpath:for-each" use="@select"/>
<xsl:key name="JPathExprs" match="jpath:value-of" use="@select"/>
<xsl:template match="xsp:page">
<xsl:apply-templates select="//jpath:if | //jpath:when | //jpath:for-each | //jpath:value-of" mode="compile"/>
</xsl:template>
<xsl:template match="jpath:if | jpath:when | jpath:for-each | jpath:value-of" mode="compile">
<xsl:value-of select="count(key('JPathExprs', concat(@test, @select)))"/>
</xsl:template>
the count() in the last template returns 0, while with the key declaration from the last mail it returns 1. This is only a repetition of the description below.
3. But if you use Xalan (not XSLTC) and the changed key declaration, it works ;-)
Regards,
Joerg
Joerg Heinicke wrote:
It's not a problem with complex expressions, but a general problem with the use Muenchian grouping mechanism. I compared the result of the command line version of Xalan 2.4.1 and this one delivered with Cocoon. I get different *wrong* results!
Transforming
D:\xml-cocoon2\src\webapp\samples\flow\examples\prefs\pages\userInfo.xsp
with
D:\xml-cocoon2\src\java\org\apache\cocoon\components\language\markup\xsp\java\jpath.xsl
in Cocoon I get the result of the complex expression:
CompiledExpression
jxpath_checkandfirstName
= jxpathContext.compile("check and firstName = ''");
but nothing about "title" and "errorMsg".
When using command line Cocoon it's the other way around.
On problem results from the key definition. If I change it to
<xsl:key name="JPathExprs" match="jpath:if | jpath:when | jpath:for-each
| jpath:value-of" use="concat(@test, @select)"/>
and later use
<xsl:apply-templates select="(//jpath:if | //jpath:when |
//jpath:for-each | //jpath:value-of)
[generate-id(.) = generate-id(key('JPathExprs',
concat(@test, @select)))]"
mode="compile"/>
at least the command line versions seems to work correctly. This needs correct XSP JPath code (no @test on jpath:for-each and jpath:value-of).
At the end something for the theory:
On <jpath:when test="check and firstName = ''">
and <jpath:when test="check and firstName">
the templates are applied, because @test is different. But after the translating the expressions will result in the same variable name, won't they? Wouldn't it be better to use something like generate-id()?
Regards,
Joerg
Ovidiu Predescu wrote:
I found the problem with the "prefs" flow sample barfing on the registration page.
The problem is definitely a Xalan problem, everything works just fine with 2.3.1, but fails on 2.4.1. The issue seems to be with the way the JPath logicsheet compiles the XPath expressions referred to in an XSP page. This is the relevant code:
<xsl:key name="JPathExprs" match="jpath:if" use="@test"/>
<xsl:key name="JPathExprs" match="jpath:when" use="@test"/>
<xsl:key name="JPathExprs" match="jpath:for-each" use="@select"/>
<xsl:key name="JPathExprs" match="jpath:value-of" use="@select"/>
and later in the logicsheet we have:
// Generate the compiled representation of the JXPath
// expressions used by this page.
<xsl:apply-templates
select="(//jpath:if | //jpath:when)
[generate-id(.) = generate-id(key('JPathExprs', @test)[1])]
| (//jpath:for-each | //jpath:value-of)
[generate-id(.) = generate-id(key('JPathExprs', @select)[1])]"
mode="compile"/>
which is later translated into a call to:
<xsl:template name="get-var-name">
<xsl:param name="expr"/>
jxpath_<xsl:value-of select="translate($expr, " 	

~`!@%^*()-+=[]{}\|,./?><'", '')"/>
</xsl:template>
This should generate unique variable names for each <jpath:*> element in an XSP page. For example if the page refers to:
<jpath:value-of select="firstName"/>
the equivalent compiled code is:
jxpath_firstName
= jxpathContext.compile("firstName");
Xalan 2.4.1 seems to have problems while trying to generate code for more complex XPath expressions like:
<jpath:when test="check and firstName = ''">
It will silently ignore the instructions above and not generate any code which precompiles the XPath expression.
Bummer! I have no idea how to work around this problem. I'll try to come up with a simpler testcase, outside of Cocoon that reproduces the bug and log it in as a bug in Xalan. In the meantime it would be really nice if someone has a good workaround for this problem.
An obvious one is to revert to Xalan 2.3.1, but I'm not sure this is something desirable. Any thoughts? Does anyone depend on any special features from 2.4.1?
Regards,
Ovidiu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
