[Zope-dev] Re: Five and browser-oriented components

Martijn Faassen faassen at startifact.com
Thu Apr 10 09:16:42 EDT 2008


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



More information about the Zope-Dev mailing list