Return-Path: 
 <dev-return-53804-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 98092 invoked from network); 8 Jan 2004 17:04:57 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 8 Jan 2004 17:04:57 -0000
Received: (qmail 54221 invoked by uid 500); 8 Jan 2004 17:04:48 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 53966 invoked by uid 500); 8 Jan 2004 17:04:46 -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 53953 invoked from network); 8 Jan 2004 17:04:46 -0000
Received: from unknown (HELO smtp.nada.kth.se) (130.237.222.202)
  by daedalus.apache.org with SMTP; 8 Jan 2004 17:04:46 -0000
Received: from nada.kth.se (fw96.lentus.se [192.58.197.96] (may be forged))
	(authenticated bits=0)
	by smtp.nada.kth.se (8.12.10/8.12.1) with ESMTP id i08H4l81017490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <dev@cocoon.apache.org>; Thu, 8 Jan 2004 18:04:48 +0100 (MET)
Message-ID: <3FFD8CB3.1070603@nada.kth.se>
Date: Thu, 08 Jan 2004 18:00:35 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.6a) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: [ANN] Module Source and XModule Source
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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

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.

/Daniel