Re: Bugtracker for z3c.relationfield and reasons for objects loosing their parent pointers

On Tue, Mar 27, 2012 at 3:50 PM, Patrick Gerken <[email protected]> wrote:
> Hmm, since I didn't understand what magic happens with __parent__ pointers,
> I tried the following in pdb:
> unwrapped = aq_base(a)
> unwrapped.__parent__ = aq_base(a.__parent__)
>
> So I stored a not acquisition wrapped object onto the __parent__ attr
> of another unwrapped object.
> But then the result, unwrapped.__parent__ was acquisition wrapped again!

Yep. That's one thing we changed in Acquisition and ExtensionClass
4.0a1: Prevent wrappers to be created while accessing __parent__ on
types derived from Explicit or Implicit base classes.

Usually accessing any attribute on a type derived from
Acquisition.Explicit or Implicit will force wrapping to take place,
unless there's already a wrapper present. Maybe you remember the whole
weird story with browser views in Zope 2 and the need for using
"context = aq_inner(self.context)". That was the same problem.
Accessing the context attribute of the view (self), created a wrapper
equivalent to: "context = context.__of__(self)", as the view itself
wasn't wrapped in anything. For views we got rid of the problem by
removing the Acquisition.Implicit base class.

For normal content classes in Zope 2, removing the Implicit base class
is much harder, as there's more stuff depending on it, and you'd need
to ensure to switch every type derived from this, to manually store
parent pointers. But the 4.0a1 releases of AQ/EC at least treat
__parent__ differently, as it doesn't make much sense to force
wrapping for that particular attribute.

Hanno
_______________________________________________
Zope-Dev maillist  -  [email protected]
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )