cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <>
Subject Re: [RT] Access to the object model
Date Mon, 19 May 2003 17:25:53 GMT
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 ?").

That dilemma is a direction of research in Avalon. The Merlin container 
supports component meta-info that declares required context entries.

 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.

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

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


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



View raw message