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
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
