From: Daniel Fagerstrom > I just committed two new sources to the scratchpad: > > * 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.
If you have time some examples would be great! Especially the mentioned flowscript scenario. Best regards, Reinhard
