Return-Path: 
 <dev-return-54024-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 9063 invoked from network); 13 Jan 2004 22:27:46 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 13 Jan 2004 22:27:46 -0000
Received: (qmail 10815 invoked by uid 500); 13 Jan 2004 22:27:31 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 10539 invoked by uid 500); 13 Jan 2004 22:27:29 -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 10519 invoked from network); 13 Jan 2004 22:27:28 -0000
Received: from unknown (HELO paris.dvs1.informatik.tu-darmstadt.de)
 (130.83.27.43)
  by daedalus.apache.org with SMTP; 13 Jan 2004 22:27:28 -0000
Received: from informatik.tu-darmstadt.de
 (IP-213157001131.dialin.heagmedianet.de [213.157.1.131])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by paris.dvs1.informatik.tu-darmstadt.de (Postfix) with ESMTP id 743A4FE48
	for <dev@cocoon.apache.org>; Tue, 13 Jan 2004 23:27:30 +0100 (MET)
Message-ID: <400470CD.9000708@informatik.tu-darmstadt.de>
Date: Tue, 13 Jan 2004 23:27:25 +0100
From: Christian Haul <haul@informatik.tu-darmstadt.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.6b) Gecko/20031221 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [ANN] Module Source and XModule Source
References: <3FFD8CB3.1070603@nada.kth.se>
In-Reply-To: <3FFD8CB3.1070603@nada.kth.se>
X-Enigmail-Version: 0.82.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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

Daniel Fagerstrom wrote:

<snip what="cool stuff"/>

> 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?

Sorry for the late reply. I had a reply started but no time to finish... :-(

Ok, quoting the docs for request attributes for example:

    Attribute names should follow the same conventions as package names.
    Names beginning with java.*, javax.*, and com.sun.*, are reserved for
    use by Sun Microsystems.

Second, I believe hardly any module should be used as is but one should
create a "private" instance that corresponds to a certain contract. This
way it will quite simple to change the storage location.

So, I believe for every application a new instance of those modules
should be used. This is a great chance to configure the key prefix :-)
The default prefix is kind of an extra motivation for doing it ;-)

> 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".

According to the above reasoning, it would be best to configure two new
instances eg "xmodule-one" and "xmodule-two", both using eg. 
"org.apache.cocoon.samples.xmodule" as a key or none at all if that 
suits you better.

Consequently, one should create instances of input-modules that
automatically add those prefixes eg by wrapping the session and request
attribute modules with a simple mapping meta module.

<component-instance name="xmodule-one"
     class="...SimpleMappingMetaInputModule ....>
     <input-module name="request-attr"/>
     <prefix>org.apache.cocoon.samples.xmodule:</prefix>
</component-instance>


> 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.

Mind you, easy access to modules from flow has been removed :-|

Speaking of modules: since the object model may be obtained from the 
CocoonComponentManager through a static method, we might change their
signature and remove the need to pass the object model to them.

	Chris.