-1
The whole point of sticking with Zope2 is backward compatibility,
isn't it? If I wanted something that doesn't run my old products and
applications anymore I would go to Zope3 directly, why thank you.
Please keep this in mind in your spree to make Zope2 look like Zope3.
Backward compatibility is paramount. Next thing you are going to
remove implicit acquisition ;-).
Stefan
On 28. Mai 2006, at 12:53, Philipp von Weitershausen wrote:
That's true. However, we really want the Zope 2 request to
(eventually)
become like the Zope 3 browser request. In fact, in many places we
already assume that the Zope 2 request is like a Zope 3 browser
request.
We stick IBrowserRequest on it and hand it over to lots of Zope 3
machinery. So far this has worked relatively well, but there are
problems coming up with certain API subtleties.
I think the biggest challenge will be to deprecate __getattr__ access
for request variables and only allow __getitem__ for this. Then, the
getattr protocol will be used to access the request API only. For
example, IBrowserRequest demands that requests have a 'debug'
attribute.
In Zope 2, we have the problem that request.debug is an alternate
spelling of request.form['debug']. If that alternate spelling wasn't
there, request.debug was free for the IBrowserRequest API. Right now
we're doing a frame hack to see where the caller is coming from and
either yield request.debug or request.form['debug'].
--
Anything that happens, happens. --Douglas Adams
_______________________________________________
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 )
