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
zope.app.pagetemplate.ViewPageTemplateFile, 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
--
Florent Guillaume, Nuxeo (Paris, France) Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
_______________________________________________
Zope-Dev maillist - Zope-Dev@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 )
