cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: JXPath logicsheet problem found
Date Sat, 14 Dec 2002 14:49:28 GMT
And as last step the solution for XSLTC:

<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, 
>>> &quot;&#x20;&#x9;&#xA;&#xD;~`!@%^*()-+=[]{}\|,./?&gt;&lt;&apos;&quot;,

>>> '')"/>
>>>   </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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message