cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <reinh...@apache.org>
Subject RE: [ANN] Module Source and XModule Source
Date Thu, 08 Jan 2004 18:31:06 GMT

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


Mime
View raw message