cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Lame question...
Date Fri, 10 Dec 2004 15:18:02 GMT
Daniel Fagerstrom wrote:
> Pier Fumagalli wrote:
>> I have some quite-large tables that i use for lookups (categories, 
>> mostly, and prices). They fit pretty nicely in a DOM in memory, no 
>> problem, and they almost never change.
>> Now, I want to access those from XSLT as a variable.
>> Normally, I would aggregate the source, and pass it in the input to 
>> the processor, and then do the lookup when I need to.
>> Big waste of time, though, because normally (in Java) I'd parse the 
>> XML into a DOM (once) and pass it to the XSLT as a parameter (kind of 
>> like using the "document" function).
>> Is there something like that in Cocoon (allow to pass a full DOM as a 
>> parameter to the XSLT processor) or shall I start coding?
>>     Pier
> Something you could do that would be usefull for accessing XML databases 
> with DOM interface also (Xindice e.g. IIRC), would be to extend 
> o.a.excalibur.xml.xslt.XSLTProcessorImpl, so that it become DOM aware.
> What needs to be changed is the resolve(String href, String base) method 
> (that is used for handling document(), xsl:include and xsl:import). Now 
> it takes a href, finds a Source and transforms it to a 
> Instead one can start by 
> checking if the Source implements javax.xml.transform.dom.DOMSource, (or 
> DOMizable if we would like to make it analogous to XMLizable), if it 
> does it is just returned from resolve directly.

It's called XMLFragment, org.apache.cocoon.xml.XMLFragment, exists since Cocoon 1.


> A similar extension is needed for the transform method so that it also 
> becomes DOMSource aware.
> Then you just creates a source like e.g. XModuleSource that implements 
> DOMSource and finds and return your DOM from somewhere.
> AFAIK neither Saxon or Xalan is as efficient with a DOMSource as with 
> their internal specalized XML tree representation. But it should be much 
> more efficient than to serialize your DOM and build the internal 
> representation.
> /Daniel

View raw message