Malthe Borch wrote:
On Z2, certain imports need to come from Products.Five, to play nicely with ZPublisher and friends.


I'd like to ask for the motivation for not patching it onto the existing classes and/or modules.

Technically, I think that this is going to be hard. You'd need to patch in the magic acquisition base class. Acquisition is the main reason that some of the code needed to be duplicated - without the existence of acquisition wrappers, security checks are not made for view access and things just won't work.

We do explicit acquisition in those bits of code, but it's still a pain and leads to confusion around self.context in views being acquisition-wrapped weirdly, breaking some expectations around aq_parent.

The other argument against monkey-patching is that monkey-patching is something to be avoided if at all possible. I think it's wise to avoid it here, as it's possible. If you monkey-patched core Zope 3 classes, the chances are that you'll break Zope 3 code that assumes certain behavior.

The way to get rid of many of these problems would be to get rid of the need for acquisition. Philipp started a branch long ago that allows the acquisition system to look at a __parent__ pointer if no acquisition wrapper is present. Since our views have __parent__ pointers, this should fix the issue. This branch has been lingering in an "almost ready" state for a long time now.

In general, I think acquisition is one of the major remaining stumbling block in enabling quite a bit of straightforward Zope 3 code in Zope 2. Here are some more of my thoughts on this:

http://faassen.n--tree.net/blog/view/weblog/2008/01/30/0

Regards,

Martijn

_______________________________________________
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 )

Reply via email to