On Tue, Mar 27, 2012 at 2:53 PM, Patrick Gerken <do3cc...@googlemail.com> wrote:
> I found out, somewhat surprised, that __parent__ pointers are just
> disguised aq_parent pointers.
Are you maybe trying to use or set __parent__ on Acquisition wrappers
instead of unwrapped objects?
AQ wrappers have various attributes, among those aq_parent and
__parent__ being the same thing. If you store an actual __parent__
attribute on a "real" object, you should make sure to not wrap it in
an Acquisition context or explicitly unwrap it before we
Acquisition.aq_base(obj). You might need some compatibility code for
"Zope 3" libraries, to introduce aq_base calls in the right places.
On any one object, you use either parent pointers to real persistent
objects, or you use Acquisition. Zope 2.12 has not introduced anything
to actually store pointers to real objects. It just provides forward
compatibility, so objects that do have those pointers, can avoid using
Acquisition. And all of that while keeping the Acquisition API's like
"from Acquisition import aq_parent, aq_get") intact and working for
both types of approaches. Or well, this is a bit of a lie, Zope 2.12
actually did change things for browser views, so those don't inherit
from Acquisition anymore, but with those view.__parent__ is just the
same as view.context - so it's easier.
We worked on actually storing parent pointers on objects during last
years Zope 4 sprint at Plone Conf. But today I doubt using parent
pointers actually works. Or at least you have to be really careful
with Acquisition wrappers and cannot use API's like OFS.CopySupport or
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -