Evan Simpson wrote:
I haven't got the whole reason, but here are some of the pieces:
- never expose a "bare" object, or even one with an incomplete context
Why? You can get at it through aq_base anyway, surely? Also, Jim Fulton wrote a while back:
Sure. There is no guarentee that all objects are wrapped.
- 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?
These two together give you the part about aq_parent always being the previous acquisition result.
Yup, got that :-)
- allow recovery of containment information
Urm, didn't quite follow that :S
- base security on containment
aq_inner, right?
These two motivate the simplification of raw acquisition.
Which simplification is that?
The current acquisition implementation is thus a weird hybrid of containment and context.
I'll say ;-)
It isn't hard to convert a standard acquisition wrapper into either of the other sort. I'm going to propose adding something like the following functions: def aq_context(ob): def aq_containment(ob):
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: <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"> <dtml-var expr="aq_context(A).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"> <dtml-var expr="aq_containment(A).I"> cheers, Chris