[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