cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [ANN] Module Source and XModule Source
Date Thu, 22 Jan 2004 17:07:24 GMT
Christian Haul wrote:
> 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... 
> :-(

The same happended for me :(

Anyway, thanks for the explanation. Having thought a little bit more 
about it, I would still like to change the default behaviour to not 
having any prefix ;) I'll explain why below.

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

I had missed that. Observe however that there is no corresponding advice 
for session attributes. Now, while I think it is a very good idea to use 
name spaces for request attributes that are used "internally" in a 
webapp, e.g. within components, I think it is different for "user level" 
use of request attributes. With user level I mean things that you do in 
sitemaps, flowscripts, xsp etc. Here, IMHO, it is more natural to have 
attributes as global variables, without name space, and add name spaces 
if you want to create an isolated context. Using a default name space 
for attributes that are set from an output module creates a quite 
artificial context IMHO.

Also, IIRC, [Request|Session]AttributeOutputModule, are the only 
components in Cocoon, that use this kind of name spaces. The 
corresponding input modules, the XSP languages for attribute handling, 
FOM and maybe other components don't use any name spaces. IMO, following 
the principle of least suprise, the Cocoon components should have a 
consistent behaviour.

> 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 ;-)

Hmm, sound like a flexibility/readability tradeof to me. I more and 
more, tend to avoid flexibility that I don't need immediatly.

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

Ok, that would make my samples work without reconfiguration. If I'm the 
only one who want to change the default, I configure some new modules 




View raw message