cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Access to the object model
Date Mon, 19 May 2003 17:16:50 GMT
Carsten Ziegeler wrote:

>Peter Royal wrote:
>  
>
>>On Monday, May 19, 2003, at 09:15  AM, Carsten Ziegeler wrote:
>>    
>>
>>>I'm not sure if this is working. A component can be thread safe,
>>>but each request has an own object model, so I think at least the 
>>>context
>>>must either be thread local (which would not be that efficient) or
>>>you must store some kind of thread handler for the object model
>>>in the context. Or do I oversee something?
>>>      
>>>
>>Ah, good point :) (I wasn't thinking everything through first thing in 
>>the morning).
>>
>>The Avalon DefaultContext actually has a solution for this.. Rather 
>>than storing the value in the context, store a placeholder object that 
>>implements the org.apache.avalon.framework.context.Resolvable 
>>interface.. When an item is retrieved from the context, the following 
>>occurs:
>>
>>             if( data instanceof Resolvable )
>>             {
>>                 return ( (Resolvable)data ).resolve( this );
>>             }
>>
>>Then you could have a core, container-level component, the 
>>ObjectModelManager such as:
>>
>>interface ObjectModelManager
>>{
>>	void setModel( Map model );
>>      Request getRequest();
>>      ...etc...
>>}
>>
>>which would be responsible for hiding the values for a given request in 
>>ThreadLocal's
>>
>>    
>>
>Ah, thanks Peter, I didn't know Resolvable - ok, that would work then.
>
>  
>
>>And then the object that is stored in the context would just do a 
>>callback to the ObjectModelManager whenever a context value is 
>>requested (so for ThreadSafe components, the context value would need 
>>to be looked up whenever it is needed, thus guaranteeing that you 
>>always retrieve what you want).
>>
>>Of course now that I think this through more, its just more trappings 
>>on top of your original (a) proposal :)  It seems somehow cleaner to me 
>>as components don't have to deal with the static accessor methods 
>>themselves though..
>>
>>    
>>
>Yes, I currently don't know which way is better. Using Context and
>Resolvable is somehow cleaner (IoC), but the static version is very
>simple. Hmm, has anyone else an opinion?
>  
>

(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 
?").

(a) is the easiest but less clean way. Note that we already have it 
using (aaargh, I shouldn't say that) 
CocoonComponentManager.getCurrentEnvironment().getObjectModel().

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

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.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Mime
View raw message