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.
>
> 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).
>
with you all the way,
on the side, don't know for sure but maybe it makes sense to
introduce at the mean time the pattern more formally so it gets
used at more places in future (Map return from Actions comes to mind)
I've always liked the pattern of get- set- remove- Attribute and
getAttributeNames on the HttpSession, HttpRequest, and ServletContext
(it's less hard to implement this then the full Map interface if
you have something specific in mind, e.g entrySet() )
> Of course, if the object model is extended, e.g. with flow values, this
> will mean an additional entry in the context.
>
IMHO I think the main thing is stepping away from Map for these
things in general, having this technique nested down on
child-object-attributes seems quite innevitable?
> And we will have a ContextHelper class, counter part of ObjectModelHelper.
>
maybe overdoing it: but, if the pattern comes up we might even
push up a Dynamic Proxy AttributeHelper for the general case and
for reuse in user apps
> Thoughts ?
yes :-)
hope I made them clear
> Sylvain
>
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
|