* ModuleSource - That reads from streams and strings found by using an input module. It can among other things replace the StreamGenerator and the PartSource.
* XModuleSource - Read and write XML data (DOM and XMLizable) from input and output modules. Can replace the [Read|Write]DOMSessionTransformers and should also be usfull in flowscripts together with processToStream.
I have some problem with the default behaviour of the [Request|Session]AttributeOutputModules, that is descibed below, please comment if you have any suggestions (Chris?).
The idea and design are based on a discussion with Vadim and Sylvain: http://marc.theaimsgroup.com/?t=106908681200005&r=1&w=2 .
ModuleSource ============
Readable source that are accessed with URI:s like:
module:<input-module>:<attribute-name>[#xpath]
For reading the object that is found by applying the XPath (JXPath), on the attribute from the input-module. If the object is a String or an InputStream, it made available in form of an InputStream otherwise an exception is thrown.
The module source can be used for various things e.g. instead of the StreamGenerator:
<map:generate type="file" src="module:request:inputStream"/>
For reading html from a input field in a form:
<map:generate type="html" src="module:request-param:html-field"/>
Instead of the PartSource for reading multi part mime data:
module:raw-request-param:foo
To use this uploads must be enabled in web.xml.
It can also be used for more advanced things like reading Wiki content from a textarea
<map:generate type="text" src="module:request-param:wiki-field"/> <map:transform type="lexer" src="cocoon:/wiki.xlex"/> <map:transform type="parser" src="cocoon:/wiki.xgrm"/> <map:transform src="stylesheets/wiki2xdoc.xsl"/>
I didin't made the module source modifiable as I had no clear use cases for it, nor was it obvious to me in what form to save the input.
XModuleSouce ============
Read and writable source that are accessed with uri:s like:
xmodule:[<input-module>|<output-module>]:<attribute-name>[#xpath]
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.
Open Issue ----------
A peculiarity in the RequestAttributeOutputModule and
SessionAttributeOutputModule is that they as default prefix all attribute names with org.apache.cocoon.components.modules.output.OutputModule", why?
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:
<key-prefix/>
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 booth an input and an output module that are configured to have the same name and that gets and sets the same attribute.
Could we change the default behaviour for the [Request|Session]AttributeOutputModules so that they not prepending any "name spaces" as default. I found the current behaviour rather strange, but maybe I am missing something.
--------
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.
/Daniel
