Scratchpad component


Read and write XML data (DOM and XMLizable) from input and output modules. This can replace the [[''''[Read|]|[Write|]]DOMSessionTransformers and should also be useful in flowscripts together with process!ToStream.

Read and writable source that are accessed with uri:s like:


For reading the object that is found by applying the XPath (JXPath), on the attribute from the input-module, is supposed to be a DOM Document, a DOM Node or an XMLizable object, the object is serialized to SAX.

For writing the input is serialized into a DOM Document, this document is put in the attribute from the output-module if the XPath is empty. If the XPath not is empty, an input-module is used to find the attribute and JXPath is applied. If the object that is found is a DOM tree, the input document is imported into it, otherwize it is just assigned into that position.

There is a delete fuction as well, that use removeAll(xpath) from JXPath.

Flow example


RequestAttributeOutputModule and SessionAttributeOutputModule as default prefix all attribute names with org.apache.cocoon.components.modules.output.OutputModule.

To make the samples for the xmodule source work this must be reconfigured to using attribute names without prefixes. This is done in the cocoon.xconf by puting an empty key-prefix" element:


as child to the configurations of the output-modules "request-attr" and "session-attr".

To make writing with or without XPaths work in a decent way, there is supposed to be both an input and an output module that are configured to have the same name and that gets and sets the same attribute.

Relation to [Read||Write]!SessionTransformers

For the [[Read|Write]DOMSessionTransformers as well as the [[Read|Write]DOMTransformers submitted in, I would guess that the read functionality can be replaced by using URIs like:


together with the [[C|X]IncludeTransformer or the FileGenerator. The write functionality can probably be replaced by using URIs on the same form together with the SourceWritingTransformer or doing the writing by using processToStream within flowscripts.

Writing to the xmodule stream is less efficient than using the WriteDOMSessionTransformer, as a serialize/reparse step is needed. This would be quite easy to fix, what we need is a convention for what interface a source that one can write SAX to should implement. I think that it would be most convinient to implement the XMLConsumer interface. Then the SourceWritingTransformer can check if the source implements XMLConsumer and in that case redirect the input events to that instead. For use within flowscripts, processToSAX can be used.

Future work

A nice enhancement would be to let the XModuleSource implement ContentHandler, then one would avoid the serialize/parse step in some cases. It could e.g. be used with processToSAX in flowscripts.

XModuleSource (last edited 2009-09-20 23:40:24 by localhost)