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 Fri, 23 May 2003 08:42:55 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>  
>
>>Carsten Ziegeler wrote:
>>    
>>
>>>Stefano Mazzocchi wrote:
>>>      
>>>
>>>>Ok, I stand corrected and I change my -1 to a +1 for a context-based reference
to the cocoon object model of general avalon components when loaded by cocoon.
>>>>        
>>>>
>>>Yuppi! So, I will try to implement it then today :)
>>>      
>>>
>>Hey, wait a bit ! We have to define first how the object model is to be
>>accessed from the context.
>>    
>>
>
>Too late :)
>

Aaargh ! You're too fast ;-)

>Seriously, yes you are right - I'm just trying to implement something that is working
and wanted to refine it later on.
>  
>
>>I see two ways :
>>
>>1 - the object model as a whole is accessible as a context entry :
>>      Map objectModel = (Map)context.get(CTX_OBJECT_MODEL);
>>
>>2 - each of the element of the object model can be accessed separately :
>>      Request req = (Request)context.get(CTX_REQUEST);
>>
>>I don't like solution 1, as it exposes the fact that object model elements are stored
in a Map, which really is an implementation detail (remember discussions long ago about defining
an ObjectModel class ?).
>>
>>So my preference goes to solution 2, which exposes directly the elements of the object
model, without caring if they are all gathered in a Map, or independently set in the context
though ThreadLocals, or whatever implementation choice is made. Furtheremore, the Context
being already analoguous to a Map, there's no need, from the user point of view, for an additional
indirection (the map may however be kept under the hood for the implementation).
>>    
>>
>
>Yes, I agree that 1 is not the best choice.
>  
>
>>Of course, if the object model is extended, e.g. with flow values, this will mean
an additional entry in the context.
>>    
>>
>Yes, and this is the part I don't like about 2 :)
>  
>
>>And we will have a ContextHelper class, counter part of ObjectModelHelper.
>>    
>>
>Why? We defined ObjectModelHelper because there was the discussion that a Map is perhaps
not the best choice for the object model and we perhaps will sometime change the implementation
from Map to an custom implementation. By using ObjectModelHelper we could perhaps maintain
a little bit of compatibility.
>And the other reason was strong typing.
>

Considering that ObjectModelHelper takes a "Map objectModel" argument, 
ObjectModelHelper mainly brings strong typing and avoidance of knowing 
that the keys are.

>Anway, how should this ContextHelper look like?
>
>ContextHelper.getRequest(Context)
>ContextHelper.getResponse(Context)
>etc.
>

Yep.

>Ok, I'm wondering if we could make a deal between your solution 1 and 2 like
>
>Object o = context.get(Constants.CONTEXT_OBJECT_MODEL + OBJECT_MODEL_REQUEST);
>
>so every get() that starts with Constants.CONTEXT_OBJECT_MODEL is 'redirected' into the
object model and the rest of the key is passed into the object model map.
>
>What do you think?
>

The keys used to access Context information are the contract between the 
container and the application. So we can choose whatever naming we want 
provided that this naming is known to the people that write components, 
either through documentation, a bunch of constants, a ContextHelper 
class or a naming convention as described above.

So... deal !

We can also have some predefined constants for entries that are always 
present in the object model, e.g. :
  String CONTEXT_REQUEST = CONTEXT_OBJECT_MODEL + OBJECT_MODEL_REQUEST;

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