cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Fiol Bonnín <antonio.f...@gmail.com>
Subject Fwd: document(...) broken when using xsltc
Date Tue, 02 Aug 2005 07:46:30 GMT
Hello,

I have not reveived any useful tips from the users mailing lists. As this 
might be a cocoon bug, or else a XSLTC bug, I am forwarding this to dev@.

Can anyone please help me find if there is a problem in my XSLT code or 
point me to somewhere to look for and try to repair the bug in cocoon or 
XSLTC.

Thank you very much.


-- 
Antonio Fiol

---------- Forwarded message ----------
From: Antonio Fiol Bonnín <antonio.fiol@gmail.com>
Date: 28-jul-2005 9:32
Subject: Re: document(...) broken when using xsltc
To: users@cocoon.apache.org

2005/7/27, Joerg Heinicke <joerg.heinicke@gmx.de>:
> 
> On 27.07.2005 15:54, Antonio Fiol Bonnín wrote:
> 
> > I have been changing my transforms to execute with XSLTC instead of
> > interpreted Xalan. However, some of them did not work properly, showing
> > erratic behaviour, or even throwing NullPointerException. 
> >
> > In most cases (if not all), I have tracked the problem to usage of the
> > document() function to get information from another source document. 
> When
> > this function is used, the context node is lost, and thus strange things 
> 
> > happen.
> >
> > When I say "the context node is lost", I mean that AFTER the call to
> > document():
> > - any xpath expressions I've tried lead to erratic behaviour AND
> > - in some cases, the "flow" of pattern applying gets wrong (usually 
> aborting 
> > an apply-templates before applying to all the selected elements, and
> > possibly adding spurious non-empty text nodes on the output).
> >
> > Has anyone also found this problem? If so, is there another solution 
> apart 
> > from not using document() or not using xsltc? Is it a xsltc bug, a 
> cocoon
> > bug or not a bug at all?
> 
> Are you sure you have only retrieved a node using document() and not
> switched the context to the other document? 
> 


Well, I think so...

This is one of the failing templates:

<xsl:template match="*" mode="cell">
<xsl:variable name="nombre">html:<xsl:value-of 
select="name()"/></xsl:variable>
<xsl:choose>
<xsl:when 
test="document('')/xsl:stylesheet/xsl:template[contains(@match,$nombre) and 
@mode='inline']">
<xsl:apply-templates select="." mode="inline"/>
</xsl:when>
<xsl:otherwise>
<xsl:apply-templates select="." mode="block"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>

The intention of this template is doing a sort of reflection upon the 
stylesheet. Adding e.g. an <xsl:comment> before both <xsl:apply-templates> 
shows that the right <xsl:apply-templates> is executed. However, it is 
executed against the <xsl:apply-templates> element itself!! which is not the 
intended behaviour.

In a particular case (which I have not been able to track down to a simple 
example), it even leads to a NullPointerException.

Mime
View raw message