[Zope-dev] Re: zope2 requests VS zope3 requests

[Chris McDonough]

On May 28, 2006, at 6:53 AM, Philipp von Weitershausen wrote:

> Lennart Regebro wrote:
>> On 5/27/06, Rocky Burt <rocky at serverzen.com> wrote:
>>> I've heard rumours that ultimately the preferred manner of  
>>> integration
>>> of z2 and z3 requests was to replace the z2 ZPublisher with the z3
>>> zope.publisher.
>>
>> Well, that would not necessarily mean that the requests are the  
>> same. :-)
>
> That's true. However, we really want the Zope 2 request to  
> (eventually)
> become like the Zope 3 browser request. In fact, in many places we
> already assume that the Zope 2 request is like a Zope 3 browser  
> request.
> We stick IBrowserRequest on it and hand it over to lots of Zope 3
> machinery. So far this has worked relatively well, but there are
> problems coming up with certain API subtleties.
>
> I think the biggest challenge will be to deprecate __getattr__ access
> for request variables and only allow __getitem__ for this. Then, the
> getattr protocol will be used to access the request API only. For
> example, IBrowserRequest demands that requests have a 'debug'  
> attribute.
> In Zope 2, we have the problem that request.debug is an alternate
> spelling of request.form['debug']. If that alternate spelling wasn't
> there, request.debug was free for the IBrowserRequest API. Right now
> we're doing a frame hack to see where the caller is coming from and
> either yield request.debug or request.form['debug'].
>
> request.debug is just the beginning. At some point we might want to  
> make
> use of Zope 3 locales and support request.locale. request.principal
> might make sense when the Zope 3 security mechanism makes it into  
> Zope 2
> at some point...
>
> As said, I think the first step towards unifying the request  
> interfaces
> would be to deprecate the __getattr__ protocol for request  
> variables. I
> think we should start with Zope 2.11.

I'm sure you know this, but I wanted to point out that doing this  
will break a lot of third-party code.  A ton of third-party code  
relies on being able to use __setattr__ and __getattr__ on the  
request object to do per-request caching.

Maybe we should just solve the "form.debug" problem for now in 2.11  
(it's a method that is hardly ever, ever used, so it can likely be  
renamed without much of a problem) and see where that gets us?

- C