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.