cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Access to the object model
Date Mon, 19 May 2003 18:51:34 GMT
Peter Royal wrote:

> On Monday, May 19, 2003, at 01:16  PM, Sylvain Wallez wrote:
>> (c) seems cleaner, as it builds on the standard Avalon lifecycle 
>> interfaces, but the problem with the Context is that it's a kind of 
>> "black hole" : we don't always know what's inside, and it may be 
>> difficult to track usage of particular Context entries in the source 
>> code (e.g. "what do I need to put in this component's context to test 
>> it ?").
> <aside>
> That dilemma is a direction of research in Avalon. The Merlin 
> container supports component meta-info that declares required context 
> entries.
> </aside> 

That's cool. I shamely admit I'm a bit lost in the "modern" Avalon 

> From a practical standpoint, abusing the "Constants in an Interface" 
> paradigm, as long as all access to the item via the Context is done 
> using the constant, it can be found with a "Find Usages" in modern 
> IDEs. Its policy to use that vs a technological requirement though.

You're right. And this is not different from what we have today with 
ComponentManager/ServiceManager.lookup(). I always compared the Avalon 
context to the servlet context, meaning a holder for global and 
unchanging data, but realize now that I'm wrong and that Context is more 
the data counterpart to the CM/SM : we lookup services on CM/SM, and 
data on the Context.

Ah, and something that has been itching me for a long time is Cocoon 
environment's Context (which, this time, is similar to the servlet 
context). If the Avalon Context gets much more used, wouldn't it be good 
to rename Cocoon's Context as EnvironmentContext, to avoid ambiguities 
and name conflicts ?

>> (b) adds yet another lifecycle interface (and the associated overhead 
>> in lookup()), which differenciate Cocoon components from "regular" 
>> Avalon components. But if those components need some parts of the 
>> object model, then they are no more regular Avalon components.
> Yes, but the coupling to Cocoon is still lower, as the mythical 
> "cocoon component user outside of cocoon" just has to synthesize 
> implementations for the required interfaces vs supporting custom 
> lifecycle interfaces.

Good point !

>> At the end, I don't know between (c) and (b). I would say (c), but 
>> with a ContextHelper class offering what currently is in 
>> ObjectModelHelper.
> +1
>> This also mean that the objectModel parameter to the setup() method 
>> is going to be useless. As SourceResolver already is, I see more and 
>> more the need of some cleanup of SitemapModelComponent. But let's 
>> keep this for 2.2.
> +1 

Cool. Other opinions ?


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

View raw message