Does aq_inner (and friends) still need dexterity-only environments?
I have a view from the browser that its calling method has something like this:
def __call__(self):
context = aq_inner(self.context)
parent = aq_parent(context).
...
Putting pdb at the start and playing with it seems like Dexterity doesn't need to use it, right?
ipdb> self.context, id(self.context), self.context.__class__
(<Container at /plone/ausgaben>, 4651890160, <class 'plone.dexterity.content.Container'>)
ipdb> aq_inner(self.context), id(aq_inner(self.context)), aq_inner(self.context).__class__
(<Container at /plone/ausgaben>, 4651890160, <class 'plone.dexterity.content.Container'>)
So the result is the same as using aq_inner or not.
So the question is, does Dexterity (like self.context and in our project actually everything based on Dexterity) do not allow us to wrap everything with aq_inner and aq_parent etc. and instead use objects or __parent__
pointers directly ?
source to share
Like AT contenttypes, DX content types are also aq-wrapped. Thus, you will run into the same behavior (problems :-)) as with AT.
As sppton said in his aq_parent(instance) == instance.__parent__
. The parent pointer is still obtainable.
But there are slight differences from AT.
If you create a new DX obj the following will happen:
-
createContent will be called, which creates the DX obj. At the moment, the content is not yet complete. So, if you subscribe to
ObjectCreatedEvent
, you won't have aq-wrapped obj. -
addContentToContainer will be called, which adds the generated DX content to the container. B
container._setObject
will be launchedObjectAddedEvent
. If you subscribed to this event, you will have ax-wrapped dx content.
In AT this is different, of course other events are fired for this case, but the AT content is always aq-wrapped (also in the factory, adding a new AT obj)
Please let me know if I misunderstood something.
source to share