Steve Alexander wrote:
That makes for a lot of security checks.
There are possible optimisations, though. But this starts to get even
more complicated.
Does that mean it won't work, would be very slow, or both? ;-)
cheers for looking though...
Chris
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/
Chris Withers wrote:
Steve Alexander wrote:
That makes for a lot of security checks.
There are possible optimisations, though. But this starts to get even
more complicated.
Does that mean it won't work, would be very slow, or both? ;-)
It will work. It will be slower.
I think Evan
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
From: Chris Withers [EMAIL PROTECTED]
- never expose a "bare" object, or even one with an incomplete context
Why? You can get at it through aq_base anyway, surely?
Only from unrestricted code. DTML and (CVS) Python Methods only let you
access aq_parent. This only applies to objects that
Michel Pelletier has reminded me that we need a security check by
containment at each point in the search through context.
So, in my example, the search will look like this:
/
|-Aa
| |-B b
|
|-Xx
| |-P p1
| |-Y y
|
|-Pp0
Context-first
Acquisition (P
Evan Simpson wrote:
So, is the working below now correct? (I feel like I'm back in School
doing maths ;-)
Yes.
Cool :-)
Where is the order of simplification defined?
In the Acquisition machinery, which simplifies upwards because that's the
way it constructs the wrappers.
okay...
Chris Withers wrote:
Steve Alexander said he was going to have a think, but I haven't heard
anything since he mentioned it...
I'll have to start running a Kibo-bot soon :-)
I've got as far as defining the difference between the two acquisition
behaviours.
Warning: The following goes into
Evan Simpson wrote:
Here are the two and a half rules for deriving acquisition from a dotted
expression:
1. A.B == (B o A), where A is an unwrapped object
2. (self o parent).B ==
a. (self.B o (self o parent)), if B is found in 'self'
b. (parent.B o (self o parent)), if B is
Hi Jim, (or any zope-dev'ers who can explain this ;-)
I've just been reading:
http://www.zope.org/Members/jim/Info/IPC8/AcquisitionAlgebra
...and I've got confused on the 'Getting the containment wrapper'
section.
In anser to 'What is A.B.C.D?' I can't see how you can get:
((D o (C o A)) o (B
I still don't get this :(
Here's the situation:
A has attributes B and C, C has attribute D
my old working:
A.B.C.D = (B o A) : .C.D
now, since C is found in A:
= ((C o A) o (B o A)) : .D
again since D is found in C:
= ((D o C) o ((C o A) o (B o
11 matches
Mail list logo
