Re: Poor performance of document() in XSL [Was: Re: simpel cocoon question]
On Thursday, Nov 7, 2002, at 16:19 Europe/London, Joerg Heinicke wrote: normally this won't work. You create a Result Tree Fragment in $colours and have to convert it to a node set using node-set() extension function. This is not possible when using XSLTC. Sorry for the red-herring! I did not actually test it, I should have . regards Jeremy - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Poor performance of document() in XSL [Was: Re: simpel cocoon question]
On Wednesday, Nov 6, 2002, at 21:26 Europe/London, Stephen Ng wrote: I say, document() is good for rapid prototyping, but is a poor choice for final deployment for performance reasons. Use aggregation instead. The Cocoon developers recommend to use aggregation or xinclude because of SoC (XSLT is for transforming, not for aggregating content). Sure, but I have a big lookup table in an xml file--it seems much more natural to reference the lookup table from xslt using document rather than to jam it into my content stream You may find, if you re-encode your lookup table as XSLT variables, that you can 'include' your data as XSLT into your stylesheet. eg. constants.xslt: xsl:variable name=colours colour id=white#fff/colour colour id=black#000/colour colour id=grey#888/colour /xsl:variable main.xslt: xsl:include src=constants.xslt/ .. xsl:template match=foo xsl:variable name=colour select=@colour/ bar xsl:attribute name=colour xsl:value-of select=$colours[@id=$colour]/ !-- or is it: xsl:value-of select=$colours/colours[@id=$colour]/ -- /xsl:attribute /bar /xsl:template Hope this helps regards Jeremy - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Poor performance of document() in XSL [Was: Re: simpel cocoon question]
I say, document() is good for rapid prototyping, but is a poor choice for final deployment for performance reasons. Use aggregation instead. The Cocoon developers recommend to use aggregation or xinclude because of SoC (XSLT is for transforming, not for aggregating content). Sure, but I have a big lookup table in an xml file--it seems much more natural to reference the lookup table from xslt using document rather than to jam it into my content stream --Steve - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Poor performance of document() in XSL [Was: Re: simpel cocoon question]
SAXESS - Hussayn Dabbous wrote:
snip/
But you also could do it directly within the xslt context:
You can use the document() function in your XSLT-file.
This function allows you to refer to data contained within
another XML-file. This is completely decoupled from cocoon
though. It's more about how to work with XSLT:
snip/
In the past I have encountered a nasty performance problem with document().
For example, when you declare an xsl variable that gets its value from a
document(),
and then use its value several times throughout the stylesheet, the URI
of the document
gets hist as many times as there are references to that variable. I.e.
the xsl variable
does not store the XML fragment it was given at the variable definition
time, but
merely stores the XPath string and then resolves it every time it's
referenced.
This may or may not be true for XPath expressions that do not contain
document()
as well. Does anyone know for sure?
Example:
xsl:variable name=test-me
select=document('cocoon:/gimme-sumthn')/sumthn/in/@there/
xsl:template match=/
this-is-just-a-test
xsl:value-of select=$test-me/
xsl:value-of select=$test-me/
xsl:value-of select=$test-me/
/this-is-just-a-test
/xsl:template
When using Xalan, this example will cause the Cocoon pipeline that
is responsible for gimme-sumthn to be hit three times. I say,
document() is good for rapid prototyping, but is a poor choice for final
deployment for performance reasons. Use aggregation instead.
+2c
--
Ilya
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Poor performance of document() in XSL [Was: Re: simpel cocoon question]
A naive implementation of the document() function is likely
to do this. However happily, by implementing the
javax.xml.transform.URIResolver interface [1], and setting
this on the Tranformer using setURIResolver [2] you can easily
plug in a simple cache (e.g. hash of URL versus retrieved content)
that avoid multiple network overheads.
I have a sample implementation and simple test harness
if anyone wants it.
Cheers,
L.
[1]. http://java.sun.com/j2se/1.4/docs/api/javax/xml/transform/URIResolver.html
[2].
http://java.sun.com/j2se/1.4/docs/api/javax/xml/transform/Transformer.html#setURIResolver(javax.xml.
transform.URIResolver)
-Original Message-
From: Ilya A. Kriveshko [mailto:ilya;kaon.com]
Sent: 05 November 2002 14:33
To: [EMAIL PROTECTED]
Subject: Poor performance of document() in XSL [Was: Re: simpel cocoon
question]
SAXESS - Hussayn Dabbous wrote:
snip/
But you also could do it directly within the xslt context:
You can use the document() function in your XSLT-file.
This function allows you to refer to data contained within
another XML-file. This is completely decoupled from cocoon
though. It's more about how to work with XSLT:
snip/
In the past I have encountered a nasty performance problem with document().
For example, when you declare an xsl variable that gets its value from a
document(),
and then use its value several times throughout the stylesheet, the URI
of the document
gets hist as many times as there are references to that variable. I.e.
the xsl variable
does not store the XML fragment it was given at the variable definition
time, but
merely stores the XPath string and then resolves it every time it's
referenced.
This may or may not be true for XPath expressions that do not contain
document()
as well. Does anyone know for sure?
Example:
xsl:variable name=test-me
select=document('cocoon:/gimme-sumthn')/sumthn/in/@there/
xsl:template match=/
this-is-just-a-test
xsl:value-of select=$test-me/
xsl:value-of select=$test-me/
xsl:value-of select=$test-me/
/this-is-just-a-test
/xsl:template
When using Xalan, this example will cause the Cocoon pipeline that
is responsible for gimme-sumthn to be hit three times. I say,
document() is good for rapid prototyping, but is a poor choice for final
deployment for performance reasons. Use aggregation instead.
+2c
--
Ilya
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
