From: Chris Withers <chrisw@nipltd.com>
Who would be best to ask why it was set up the way it is?
I'm sure there are very good reasons for it but the search order in all but the simple cases is very confusing and not as useful as it could be.
How much more work would it be to implement the following algorithm, regardless of how the actual containment is? [snip]
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 - allow the user to backtrack along the context chain These two together give you the part about aq_parent always being the previous acquisition result. - allow recovery of containment information - base security on containment These two motivate the simplification of raw acquisition. With the simplification, you get containment-first search and aq_inner.aq_parent gives you your fully-wrapped container. The current acquisition implementation is thus a weird hybrid of containment and context. It retains both sorts of information while providing the search semantics we want security to have. 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): context = [] while ob is not None: context.append(ob.aq_base) ob = ob.aq_parent ob = context.pop() while context: ob = context.pop().__of__(ob) return ob def aq_containment(ob): context = [] while ob is not None: context.append(ob.aq_base) ob = ob.aq_inner.aq_parent ob = context.pop() while context: ob = context.pop().__of__(ob) return ob ... so that you could write something like <dtml-var expr="aq_context(foo).bar"> or <dtml-with foo context>&dtml-bar;</dtml-with>. In the meantime, they make fine External Methods. Cheers, Evan @ digicool & 4-am