Christopher Oliver wrote:Why not have processPipelineTo take a javax.xml.transform.Result instead of an OutputStream?
Yes, that might be a good solution (although back incompatible IIUC). Buffering in a byte array might also work. I'm just (overly?) worried about the performance penalty of serialization/parsing which does not take place with Sylvain's approach. I think I'm seeking for the best of both, which might only be possible with an extra FOM method?.
Guido
While javax.xml.transform.Result is convenient for connecting to parsers, XSLT-transformers and serializing to SAX and DOM, it is not used as an external API in Cocoon. In Cocoon XMLConsumer and XMLProducer are the main API:s for transporting XML data. Furthermore it would be unpractical to use Result within Cocoon as DOMResult, SAXResult and StreamResult are classes instead of being interfaces.
I think that we need a
processPipelineToSAX(String uri, Object bizData, XMLConsumer out)
that would solve the serialization/parsing performance penalty that worry me as well. It would not introduce any new concepts in Cocoon either, when you use the cocoon protocol in e.g. an aggregator, you get SAX output from a pipeline.
As I said in an earlier post I would like to have the convenience functions: processPipelineToDOM and processPipelineToSource as well.
Concerning the question where to put these things, they should IMO be part of the FOM. XML in form of SAX and DOM, and sources are core concepts in Cocoon and should therefore be supported in the FOM.
/Daniel
