Mailing List Archive: Zope: Dev

zope2 requests VS zope3 requests

Index | Next | Previous | View Threaded

rocky at serverzen

May 27, 2006, 2:00 PM

Post #1 of 7 (1010 views)
Permalink

zope2 requests VS zope3 requests

Hi all,

After trying to get zope3-style locale information from a zope2 request
for another task today I discovered I had no idea what the plan was
regarding uniting these two request models in short-term or long-term
(or even if there are any plans).

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. Perhaps those are just rumours, I have no idea. In any
event, that would certainly be long-term.

But are we doing anything in the short-term? My naive idea was that
perhaps we should start building FrankenHTTPRequest which extended the
original ZPublisher HTTPRequest but then also implemented
zope.publisher's IHTTPRequest interface. This would give us a fairly
safe combination of both requests and enable more zope3 applications to
work as-is on Zope 2 (the one example that comes to mind is zope3's
formlib which requires locale information to be present on the active
request based on zope.publisher's IHTTPRequest).

To be honest I'm only throwing random ideas out here just to spark a
discussion. Maybe you all have already figured out the appropriate game
plan. Either way, I'd just like to know :)

- Rocky

--
Rocky Burt
ServerZen Software -- http://www.serverzen.com
News About The Server (blog) -- http://www.serverzen.net

Attachments:

signature.asc (0.19 KB)

regebro at gmail

May 28, 2006, 1:08 AM

Post #2 of 7 (965 views)
Permalink

Re: zope2 requests VS zope3 requests [In reply to]

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. :-)

> But are we doing anything in the short-term? My naive idea was that
> perhaps we should start building FrankenHTTPRequest which extended the
> original ZPublisher HTTPRequest but then also implemented
> zope.publisher's IHTTPRequest interface.

Isn't that what we are doing?

--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content Management http://www.cps-project.org/
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

philipp at weitershausen

May 28, 2006, 3:53 AM

Post #3 of 7 (966 views)
Permalink

Re: zope2 requests VS zope3 requests [In reply to]

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.

>> But are we doing anything in the short-term? My naive idea was that
>> perhaps we should start building FrankenHTTPRequest which extended the
>> original ZPublisher HTTPRequest but then also implemented
>> zope.publisher's IHTTPRequest interface.
>
> Isn't that what we are doing?

Yup.

Philipp

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

chrism at plope

May 28, 2006, 8:01 AM

Post #4 of 7 (969 views)
Permalink

Re: Re: zope2 requests VS zope3 requests [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

philipp at weitershausen

May 28, 2006, 8:12 AM

Post #5 of 7 (971 views)
Permalink

Re: Re: zope2 requests VS zope3 requests [In reply to]

Chris McDonough wrote:
>> 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.

Yeah, I know. That's why we can't just stop supporting __{g|s}etattr__,
but we'll have to 1st) discourage using it (use __getitem__ on the
request, or even request.form, request.cookies, etc. instead), 2nd)
deprecate it and 3rd) finally remove it. In either case, I think it
would be much much easier in the long term if request.something would
always be the 'something' method or attribute of the request object and
not perhaps a form variable, a method or attribute...

> 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?

The debug problem is already solved, albeit not in a very pretty manner.
request.debug is just one attribute that we want to add to the Zope 2
request API, there are more in the line (see Rocky's wish for
request.locale). The current behaviour with __getattr__ resolving to
request variables first makes it insanely hard to extend the Zope 2
request API and have predictable access to request attributes. Hence I
think deprecating __getattr__ access to request variables (forms,
cookes) should be deprecated in the long term; __getitem__ is a much
more reliable way to do this.

Philipp
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

stefan at epy

Jun 2, 2006, 2:21 AM

Post #6 of 7 (928 views)
Permalink

Re: Re: zope2 requests VS zope3 requests [In reply to]

-1

The whole point of sticking with Zope2 is backward compatibility,
isn't it? If I wanted something that doesn't run my old products and
applications anymore I would go to Zope3 directly, why thank you.

Please keep this in mind in your spree to make Zope2 look like Zope3.
Backward compatibility is paramount. Next thing you are going to
remove implicit acquisition ;-).

Stefan

On 28. Mai 2006, at 12:53, Philipp von Weitershausen wrote:

> 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'].

--
Anything that happens, happens. --Douglas Adams

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

philipp at weitershausen

Jun 7, 2006, 1:26 PM

Post #7 of 7 (869 views)
Permalink

Re: Re: zope2 requests VS zope3 requests [In reply to]

Stefan H. Holek wrote:
> -1
>
> The whole point of sticking with Zope2 is backward compatibility, isn't
> it? If I wanted something that doesn't run my old products and
> applications anymore I would go to Zope3 directly, why thank you.

Hey, the idea isn't to run Zope 3 directly but to evolve, remember? How
can we evolve if we don't ever change anything? Of course we'll provide
BBB for the usual amount of time.

> Please keep this in mind in your spree to make Zope2 look like Zope3.
> Backward compatibility is paramount.

Of course, but not forever. Eternal backward compatibility (even with
Zope 1) has lead to what Zope 2 and its various bit-rotten APIs are
today. Is it such a surprise then that Zope 3 ended up being a complete
rewrite because people realized early on that it was just way too hard
to satisfy all those weird quirks in Zope 2? Well, it turns out that we
do want to evolve Zope 2, so now we're doing all that work in cleaning
up the mess.

The amount of time I alone have spent in debugging Zope 2 because it
eats exceptions, magically acquires things or excepts this or that is
just ridiculous. But don't get me wrong, I'm not complaining. I'm just
trying to improve things.

> Next thing you are going to remove implicit acquisition ;-).

Nope :).

> On 28. Mai 2006, at 12:53, Philipp von Weitershausen wrote:
>
>> 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'].
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com