Several components that we'd like to use in Zope2, such as the
SequenceEngine from Zope3, use the Zope 3 ZPT engine to render some
things. (This has nothing to do with Zope 2 using or not using the Zope
3 ZPT engine.)

The Zope 3 ZPT engine, in particular, makes the assumption that
'request' properly implements IBrowserRequest. The Zope 2 request
doesn't implement all of it, but it's close enough to make most of the
Zope 3 stuff work. ViewPageTemplateFile, however, uses the 'debug'
property of the request (it's specified in the request interface). This
'debug' property is an instance of DebugFlags and basically is a
debugging switch for ZPT and other things.

The Zope 2 request obviously doesn't have this 'debug' property. In the
past we've usually added the necessary properties to the Zope 2 request
in such cases. We could do this again, however: The Zope 2 request
allows form data access through the __getattr__ protocol (the Zope 3
request does this through __getitem__).  request.debug would shadow a
potential 'debug' form variable and might break applications that make
use of this form variable (I would expect there are at least a couple).

Note that the obvious workaround is to use request.form['debug'] or
request.cookies['debug'], depending on where you get the variable from.
I would even say that this should be the preferred way of getting to
form variables or cookies. But given the antiqueness of the Zope 2 API
and no truly encouraged way of accessing things, there is to be expected
code that relies on request.debug being the form variable.

I would still vote for introducing the change. At some point (perhaps
even in Zope 2.10), we'll want to use more and more of the Zope 3 ZPT
engine. This problem would reoccur then. I'm therefore going to
introduce the change on the zope33-port branch, as it is necessary for
getting Five 1.5 (see Five's zope33-port branch) and Zope 2 to work with
Zope 3.3.



Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to