[Zope-dev] Re: request.debug needed for Zope 3 ZPT engine

[Florent Guillaume]

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 at nuxeo.com