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.  


> 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:

How can Steve achieve what he wants with the way acquisition currently



Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to