Return-Path: 
 <dev-return-74264-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 57492 invoked from network); 13 May 2005 11:04:14 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 13 May 2005 11:04:14 -0000
Received: (qmail 6817 invoked by uid 500); 13 May 2005 11:08:04 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 6785 invoked by uid 500); 13 May 2005 11:08:03 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 6770 invoked by uid 99); 13 May 2005 11:08:03 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from essemtepe.nada.kth.se (HELO smtp.nada.kth.se) (130.237.222.115)
  by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 13 May 2005 04:08:03 -0700
X-Authentication-Info: The sender was authenticated as danielf using PLAIN at
 smtp.nada.kth.se 
Received: from [130.237.218.93] (cvap80.nada.kth.se [130.237.218.93])
	(authenticated bits=0)
	by smtp.nada.kth.se (8.12.11/8.12.11) with ESMTP id j4DB3Wiu025575
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <dev@cocoon.apache.org>; Fri, 13 May 2005 13:03:33 +0200 (MEST)
Message-ID: <42848983.7070309@nada.kth.se>
Date: Fri, 13 May 2005 13:03:31 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Scoped Request Attributes (was: [Vote] POJOfied Environment)
References: <42836CB8.5050901@nada.kth.se> <4283B179.9080006@reverycodes.com>
 <4283BC80.6060608@nada.kth.se> <428454DD.9010904@apache.org>
In-Reply-To: <428454DD.9010904@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Carsten Ziegeler wrote:

>Daniel Fagerstrom wrote:
>  
>
<snip/>

>>>How above Request interface additions will relate to methods already 
>>>added to 2.2 interface:
>>>
>>>   Object getAttribute(String name, int scope);
>>>   Object searchAttribute(String name);
>>>   Enumeration getAttributeNames(int scope);
>>>   void setAttribute(String name, Object o, int scope);
>>>   void removeAttribute(String name, int scope);
>>>
>>>Can any of those be renamed / reworked to be consistent with the 
>>>proposed additions? As we had no single 2.2 release yet, it's good time 
>>>to review those additions.
>>>      
>>>
>>I don't know why we need differnt scopes, maybe Carsten can comment.
>>    
>>
>The discussion about scoped attributes is here:
>http://marc.theaimsgroup.com/?t=108901128600001&r=1&w=2
>
>Basically, in 2.1.x the request attributes are shared between the global
>request and all its internal requests. So internal requests can
>overwrite attributes of the global request or of some parallel internal
>ones. And this can lead to very interesting results. So, scoped
>attributes are a way to solve this problewm.
>
>I recently added the searchAttribute() method that first looks in the
>local scope and then in the global scope for an attribute.
>
>I agree with Vadim, that we somehow should consider these things as well.
>  
>
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.

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.

WDYT?

/Daniel