cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [VOTE] Unrestricting the FOM
Date Mon, 14 Jun 2004 13:39:13 GMT
Carsten Ziegeler wrote:

>This context is a map containing key value pairs, it contains some "global" information
(paths etc.) and e.g. the object model.
>So even if we would move away from avalon we could have this map without breaking compatibility
here. That's why I'm against "avalonContext".

Ok, I understand your point. It's true that Avalon's context is 
basically an immutable Map with no means to get the list of entries. But 
if we move away from Avalon, it's very likely that this concept of 
container context will even not exist.

>We already have cocoon.context, couldn't we make things available from there?

Mmmh... don't know if it's a good idea, as the Cocoon core currently 
doesn't rely on custom attributes in the environment objects (unless I'm 
mistaken). This would complexify things a bit, IMO.

In the end, I think that either we add cocoon.avalonContext or we commit 
the ContextAccess I proposed to Jeremy (we can also merge it in 
ContextHelper). But let's not try to abstract what Avalon provides in a 
framework-independent manner as that abstraction may disappear it we 
move away from Avalon.



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message