You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Geissel, Adrian" <ad...@ecb.int> on 2003/06/03 14:26:13 UTC

C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)

Silly mail client!

> Hi all,
> 
> I building an XSP Java logicsheet, and use the following constructs:
> 
>     <xsl:template match="*" mode="ctrl-mode">
>         <xsp:logic>
>             <xsl:apply-templates select="@*" mode="ctrl-mode"/>
>             this.contentHandler.startElement(
>                       "<xsl:value-of select="namespace-uri(.)"/>",
>                       "<xsl:value-of select="local-name(.)"/>",
>                       "<xsl:value-of select="name(.)"/>",
>                       xspAttr);
>             xspAttr.clear();
>             <xsl:apply-templates select="text()|*" mode="ctrl-mode"/>
>             this.contentHandler.endElement(
>                       "<xsl:value-of select="namespace-uri(.)"/>",
>                       "<xsl:value-of select="local-name(.)"/>",
>                       "<xsl:value-of select="name(.)"/>");
>         </xsp:logic>
>     </xsl:template>
> 
>     <xsl:template match="text()" mode="ctrl-mode">
>         <xsp:logic>
> 		// snip...
>         </xsp:logic>
>     </xsl:template>
> 
>     <xsl:template match="@*" mode="ctrl-mode">
>         <!-- Filter out namespace declaration attributes -->
>         <xsp:logic>
>             tempValue="<xsl:value-of select="."/>";
>             // snip...
>             xspAttr.addAttribute(
>               "<xsl:value-of select="namespace-uri(.)"/>",
>               "<xsl:value-of select="local-name(.)"/>",
>               "<xsl:value-of select="name(.)"/>",
>               "CDATA",
>               tempValue
>             );
>         </xsp:logic>
>     </xsl:template>
> 
> 
> What I am observing is that the text() nodes are never 
> matched, even thought the source file clearly includes text 
> in the nested elements. Nested elements and attributes are 
> processed as expected.
> 
Has anyone else come across this?
Envronment is standard Cocoon 2.0.4 release running on WL7.0 on Windows NT4
SP6.

Many thanks,
Adrian

Any e-mail message from the European Central Bank (ECB) is sent in good faith but shall neither be binding nor construed as constituting a commitment by the ECB except where provided for in a written agreement.
This e-mail is intended only for the use of the recipient(s) named above. Any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited.
If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system.


Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)

Posted by Ricardo Rocha <ri...@apache.org>.
Sylvain Wallez wrote:
> Ricardo Rocha wrote:
<snip/>
>> So <xsp:text> is probably a venerable fossil today. That said, "if it 
>> ain't broken..." 
> 
> Ah yes, I remember that, now. Gosh, the ancient times of Cocoon 1.x...
> Thanks for refreshing our memory, Ricardo.

In fact, I was refering to the first Cocoon *2* XSP implementation. But,
yes, this is reminiscent of good ole' Cocoon 1...


Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ricardo Rocha wrote:

> Sylvain Wallez wrote:
>
>> IIRC (but don't ask me why), the XSP engine wraps every text node 
>> from the XSP file into <xsp:text> elements.
>
>
> In the original implementation text nodes were preprocessed and 
> escaped as string constants in accordance to the rules of the target 
> programming language. This took place prior to applying the core 
> logicsheet, where <xsp:text> nodes were to be transparently output as 
> quoted string constants.
>
> An alternative to this was using XSLT extension functions to perform 
> string escaping inside the core logicsheet itself. This was rejected 
> at the time because not all XSLT processors supported extensions and 
> they were considered not portable.
>
> Along the way, the XSPMarkupLanguage class was rewritten as a SAX 
> processor and the language-specific escaping was dropped in favor 
> of... XSLT extensions inside the core logicsheet :-)
>
> So <xsp:text> is probably a venerable fossil today. That said, "if it 
> ain't broken..." 


Ah yes, I remember that, now. Gosh, the ancient times of Cocoon 1.x...

Thanks for refreshing our memory, Ricardo.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)

Posted by Ricardo Rocha <ri...@apache.org>.
Sylvain Wallez wrote:
> IIRC (but don't ask me why), the XSP engine wraps every text node from 
> the XSP file into <xsp:text> elements.

In the original implementation text nodes were preprocessed and escaped
as string constants in accordance to the rules of the target programming
language. This took place prior to applying the core logicsheet, where
<xsp:text> nodes were to be transparently output as quoted string
constants.

An alternative to this was using XSLT extension functions to perform
string escaping inside the core logicsheet itself. This was rejected at
the time because not all XSLT processors supported extensions and they 
were considered not portable.

Along the way, the XSPMarkupLanguage class was rewritten as a SAX
processor and the language-specific escaping was dropped in favor of...
XSLT extensions inside the core logicsheet :-)

So <xsp:text> is probably a venerable fossil today. That said, "if it
ain't broken..."


Ricardo




Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Geissel, Adrian wrote:

>Silly mail client!
>  
>
>>Hi all,
>>
>>I building an XSP Java logicsheet, and use the following constructs:
>>
>>    <xsl:template match="*" mode="ctrl-mode">
>>        <xsp:logic>
>>            <xsl:apply-templates select="@*" mode="ctrl-mode"/>
>>            this.contentHandler.startElement(
>>                      "<xsl:value-of select="namespace-uri(.)"/>",
>>                      "<xsl:value-of select="local-name(.)"/>",
>>                      "<xsl:value-of select="name(.)"/>",
>>                      xspAttr);
>>            xspAttr.clear();
>>            <xsl:apply-templates select="text()|*" mode="ctrl-mode"/>
>>            this.contentHandler.endElement(
>>                      "<xsl:value-of select="namespace-uri(.)"/>",
>>                      "<xsl:value-of select="local-name(.)"/>",
>>                      "<xsl:value-of select="name(.)"/>");
>>        </xsp:logic>
>>    </xsl:template>
>>
>>    <xsl:template match="text()" mode="ctrl-mode">
>>        <xsp:logic>
>>		// snip...
>>        </xsp:logic>
>>    </xsl:template>
>>
>>    <xsl:template match="@*" mode="ctrl-mode">
>>        <!-- Filter out namespace declaration attributes -->
>>        <xsp:logic>
>>            tempValue="<xsl:value-of select="."/>";
>>            // snip...
>>            xspAttr.addAttribute(
>>              "<xsl:value-of select="namespace-uri(.)"/>",
>>              "<xsl:value-of select="local-name(.)"/>",
>>              "<xsl:value-of select="name(.)"/>",
>>              "CDATA",
>>              tempValue
>>            );
>>        </xsp:logic>
>>    </xsl:template>
>>
>>
>>What I am observing is that the text() nodes are never 
>>matched, even thought the source file clearly includes text 
>>in the nested elements. Nested elements and attributes are 
>>processed as expected.
>>
>>    
>>
>Has anyone else come across this?
>Envronment is standard Cocoon 2.0.4 release running on WL7.0 on Windows NT4
>SP6.
>  
>

IIRC (but don't ask me why), the XSP engine wraps every text node from 
the XSP file into <xsp:text> elements.

So you may want to match <xsp:text> and not text().

Hope this helps,
Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }