request.debug needed for Zope 3 ZPT engine
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. Comments? Philipp
Philipp von Weitershausen wrote:
Several components that we'd like to use in Zope2, such as the SequenceEngine from Zope3,
That's meant to say SequenceWidget, and we already *are* using it in Five, so not supporting request.debug would mean dropping support for SequenceWidget or having to reimplement it. Philipp
Philipp von Weitershausen wrote:
Philipp von Weitershausen wrote:
Several components that we'd like to use in Zope2, such as the SequenceEngine from Zope3,
That's meant to say SequenceWidget, and we already *are* using it in Five, so not supporting request.debug would mean dropping support for SequenceWidget or having to reimplement it.
What is the SequenceWidget? Sounds interesting... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Philipp von Weitershausen wrote:
Philipp von Weitershausen wrote:
Several components that we'd like to use in Zope2, such as the SequenceEngine from Zope3,
That's meant to say SequenceWidget, and we already *are* using it in Five, so not supporting request.debug would mean dropping support for SequenceWidget or having to reimplement it.
What is the SequenceWidget? Sounds interesting...
It's a widget for sequence types, such as lists and tuples. Imagine the following schema were represented as an HTML form: from zope.interface import Interface from zope.schema import List, TextLine class IFoo(Interface): alist = List(value_type=TextLine()) SequenceWidget will take care of rendering the widget for the 'alist' property. It's all explained in my book :) Philipp
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
Florent Guillaume wrote:
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.
I would go for the second option. I hadn't thought about inspecting the caller stack, it seems the least invasive option for now. Unless someone complains, I will implement it this way before the zope33-port is merged this coming week. Anything calling REQUEST.debug from the 'zope' package will see the debug flags, everything else will continue to see form variables.
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...
Yes, I think we should at least discourage __getattr__ access on the REQUEST and encourage explicit usage of request.form, request.cookies, etc. I would be fine with officially deprecating __getattr__ access in Zope 2.11. Changing the rest of Zope and third party products to use __getitem__ would mostly be a mechanical change, anyways. Lennart and Michael's work paved the way for more zope.publisher-like features in Zope 2. Regardless of whether zope.publisher will take over in Zope 2.11 already, it's a good idea to evolve the Zope 2 request interface towards the Zope 3 one. That makes the ride smoother when we do switch to the Zope 3 publishing machinery. Philipp ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
participants (3)
-
Chris Withers -
Florent Guillaume -
Philipp von Weitershausen