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.
WDYT?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
