Michel Pelletier wrote:
A.B.C.D
Look for D in C, if it's not there, look in B if it's not there, look in A
Someone correct me if I'm wrong here, but...
This is a linear search, which is the way acquisition *used* to work.
Which Zope version? ;-)
Consider:
A / B/ C/
D
(A contains B, B contains C and D).
A.B.C.D
By your desire first look for D in C, then B and then A.
Yup...
But A says "You cannot see Ds". Now, in the linear case, D is found in B, and A is never asked if this operation is permitted. This is a security violation because root policies should be enforced unless they are explicitly overidden further down.
Hurm :S I didn't say I had the answers, I was just posing the question ;-)
Further, it actually makes *more* sense because the
Well, maybe for security, but not for everyday use by people who have trouble getting their heads around (((D o C) o (C o A)) o ((C o A) o (B o A))) and the like...
Not from the perspective of the way most development is done. For example, when you want to have your children objects (whatever they may be) be acquireable, you don't need to think about the complexity of the situation, you just make sure you make them accessable in the context *of* you.
Hmmm, the thing which is bugging me is described quite nicely here: http://www.zope.org/Wikis/zope-dev/AcquisitionFeedback How can Steve achieve what he wants with the way acquisition currently works? cheers, Chris