cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: environment abstraction in Cocoon 2.2
Date Tue, 10 Oct 2006 13:56:29 GMT
Vadim Gritsenko wrote:
> Peter Hunsberger wrote:
>> On 10/10/06, Vadim Gritsenko <> wrote:
>>> Peter Hunsberger wrote:
>>>> On 10/9/06, Carsten Ziegeler <> wrote:
>>>>>> But just adding all this stuff to request attributes is not that
>>>>>> easy as
>>>>>> unfortunately sub request are sharing the attributes with the main
>>>>>> request. So whenever you use the cocoon protocol the main request

>>>>>> and
>>>>>> the sub request use the same set of attributes.
>>> Sub request by definition is the separate Request object with own set of
>>> attributes (potentially with ability to access parent or global request
>>> attributes - via special convention, may be?). Once sub request is 
>>> completed,
>>> all sub request attributes shall be discarded, leaving environment 
>>> only with
>>> parent attributes. Does it make sense?
>> It's the bit about "potentially with ability to access parent or
>> global request" that seems to be the issue really isn't it?  I can't
>> see how this would be optional?
> IIUC original issue was about adding "all request relevant information as 
> attributes of the request object". Since for sub request those will be 
> attributes of sub request, they will not interfere with parent request: sub 
> request's "objectModel" (or "flowContext", etc) will mask parent's completely 
> and thus won't allow modification of parent's "objectModel".
Unfortunately this is not the way it has been implemented. Currently the
sub request uses an own request object but *shares* the attributes map
with the parent request. And this means it can override and delete values.
I'm not sure if we can change this (if people are relying on this
behaviour it would break their code).


Carsten Ziegeler - Open Source Group, S&N AG

View raw message