cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Scoped Request Attributes
Date Fri, 13 May 2005 13:27:57 GMT
Carsten Ziegeler wrote:

>Daniel Fagerstrom wrote:
>>I missed that discussion. Anyway, IMO global request scope is nearly 
>>never a good idea. As discussed in that thread, people are into an 
>>unplesant suprise if they use global request scope for e.g. aggregation. 
>>Furthermore one introduce quite strange dependencies in the code if 
>>internal requests affects global request attributes. IMO, one should in 
>>most cases avoid letting internal requests having global side effects.
>This is a difficult topic. You can use global attributes to pass
>information from the global request to the sub requests and vice versa.
>This can be very useful sometimes.
It is indeed a difficult topic. Using global attributes does not scale 
well and make applications far to monolitic to be easy reusable. We of 
course have to support them despite that for back compability and 
because people might be used to them. But I think it would be much 
better if we saw an internal request like some kind of function call 
with in parameters and return values. Something like that is necessary 
to make e.g. blocks independent of their execution environment. One 
possiblity is to put a parameter map in the response object and make it 
local to the internal request.

>>In the thread you seemed to agree about that it was best, due to 
>>compability reasons, to keep the old global scope as default for request 
>>attributes, and make local request scope available through an extra 
>>parameter. IMO this is one of thoose cases where it is better to be 
>>brave and introduce back incompabilities than to keep an obscure 
>>behaviour. I think we should have request scope as default in 2.2, it 
>>will break some code, but there is a good workaround with the scoped 
>>attributes. And we will save most users from unpleasant suprises by 
>>having the more sensible behaviour as default.
>>If we go this way, the Map getRequestAttributes(), will have local 
>>request scope, and we could have a Map getGlobalRequestAtributes() for 
>>giving access to the global ones. But as using global request parameters 
>>is a rather uncommon use case, I don't think we need to have POJOfied 
>>support for it.
>I don't agree here. My number one concern is compatibility. Users might
>not notice that we changed this behaviour and will spend days in finding
>these problems.
I would rather consider the current behaviour as a bug and am more 
concerned about the days new user might spend on understanding why the 
default behaviour makes there applications stop working when they 
introduce aggregation. But I have no idea about how people write their 
applications, so it is maybe common to use global request attributes.

> So, either we leave it compatible or we provide an
>update tool, that rewrites every old use "getAttribute(name)" to
>getAttribute(name, global scope)" etc. But without such a tool, I'm -1
>on changing the behaviour.
Any suggestions about how to write such an update tool?

>In addition, I think it's not that uncommon to pass information between
>the main and the sub requests using global attributes.
Might be, but as described above I think we should provide better 
mechanisms if it is considered an important use case. Using global 
variables for communication between parts has rightfully been recognized 
as an anti pattern for decades. It just doesn't scale as all part must 
know and cooperate about some global resources.

>I think we should leave it the way it is and provide three maps:
>- getLocalRequestAttributes()
>- getGlobalRequestAttributes()
>- getAllRequestAttributes() - combines the two
>(We can use different names, but I think we should have this functionality).
We could do that, but it seem like a quite heavy burden for keeping 
compability with something we should have taken care of as soon as we 
introduced internal requests (although I understand that it wasn't easy 
to predict the consequences back then). The getAllRequestAttributes() 
seem like FS to me, why do you need it?


View raw message