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 fg@nuxeo.com