From: Chris Withers <chrisw@nipltd.com>
- never expose a "bare" object, or even one with an incomplete context
Why? You can get at it through aq_base anyway, surely?
Only from unrestricted code. DTML and (CVS) Python Methods only let you access aq_parent. This only applies to objects that are part of the containment hierachy, of course. Brand new objects aren't wrapped, nor are simple non-persistent types like lists and dicts.
- allow the user to backtrack along the context chain
I take it this is the reason for wrappers? Would it matter if the wrappers were structured differently to provide a different search order?
Only to anyone who depends on the current behavior :-) Also, there is a very limited range of "natural" ways to construct the wrappers. Once contructed, of course, we can fool with them in arbitrary ways.
- allow recovery of containment information
Urm, didn't quite follow that :S
We want to be able to find out what an object's container is, regardless of what we acquired it from. In raw acquisition, there's no straightforward way to do this. In simplified acquisition, aq_inner.aq_parent is the container. The simplification is the rule (A o B) o (B o C) => A o (B o C).
Okay, so taking our long-running example:
A / I B/ I C/ D
(A contains B and C, C contains D). (A contains an I, as does B) A.B.C.D
Which I, if any, would each of the following return:
All of these would search the dotted expression from right to left, so they would give you B's I.
<dtml-var expr="aq_context(A.B.C.D).I"> <dtml-var expr="aq_context(A.B.C).I"> <dtml-var expr="aq_context(A.B).I">
All of these would search the containers of the right-most object, so the first two would give you A's I, and the third B's I.
<dtml-var expr="aq_containment(A.B.C.D).I"> <dtml-var expr="aq_containment(A.B.C).I"> <dtml-var expr="aq_containment(A.B).I">
Cheers, Evan @ digicool & 4-am