Philipp von Weitershausen wrote:
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.

We can't potentially break currently perfectly working applications.
I'd propose either:

- introduce a config flag somewhere (zope.conf), off by default, switching the zope 2 REQUEST.debug to not using form/cookies/others but the proper attribute that zope 3 expects,

- or make a deep hack in zope 2 request's __getattr__ for the 'debug' case to check the caller stack for the few cases we know are needed from zope 3 code (zpt engine for instance), and at the same time emit a warning that direct access to REQUEST.debug is deprecated and that people should use __getitem__ access.

Do we also want to think about deprecating __getattr__ access to REQUEST in general? Given that the zope 2 core is not cleaned of it (I'm sure -- though I haven't looked), it would mean total deprecation wouldn't be done before 1.5 years anyway...


Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   [EMAIL PROTECTED]
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to