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 instead.
...
WDYT?
/Daniel
