Return-Path: 
 <dev-return-53812-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 58930 invoked from network); 8 Jan 2004 18:32:15 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 8 Jan 2004 18:32:15 -0000
Received: (qmail 53167 invoked by uid 500); 8 Jan 2004 18:32:04 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 53117 invoked by uid 500); 8 Jan 2004 18:32:04 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 53104 invoked from network); 8 Jan 2004 18:32:03 -0000
Received: from unknown (HELO kerberos) (62.116.51.59)
  by daedalus.apache.org with SMTP; 8 Jan 2004 18:32:03 -0000
Received: From mail ([62.116.51.60]) by kerberos (WebShield SMTP v4.5 MR1a);
	id 1073586725638; Thu, 8 Jan 2004 19:32:05 +0100
Received: from WRPO (wrpo.at.intra.efp.cc [194.107.80.153])
	by mail (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id i08IW4Y16681
	for <dev@cocoon.apache.org>; Thu, 8 Jan 2004 19:32:05 +0100
From: "Reinhard Poetz" <reinhard@apache.org>
To: <dev@cocoon.apache.org>
Subject: RE: [ANN] Module Source and XModule Source
Date: Thu, 8 Jan 2004 19:31:06 +0100
Message-ID: <000201c3d615$94db4080$1e01a8c0@WRPO>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <3FFD8CB3.1070603@nada.kth.se>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N


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