[Zope-dev] Acquisition ( slightly less Confusion ;-)

[Chris Withers]

Evan Simpson wrote:
   - 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 are part of the
 containment hierachy, of course.  Brand new objects aren't wrapped, nor are
 simple non-persistent types like lists and dicts.

Ah, okay... so really, prettymuch all Zope objects should be wrapped
with only one or two exceptions, most of which aren't actually objects
as such but simple data types?


  Would it matter if the
  wrappers were structured differently to provide a different search
  order?

 Only to anyone who depends on the current behavior :-) 

Heh, ain't backward compatability a bitch ;-)

 Also, there is a
 very limited range of "natural" ways to construct the wrappers.  Once
 contructed, of course, we can fool with them in arbitrary ways.

So I see, does this reduce efficiency at all?

 We want to be able to find out what an object's container is, regardless of
 what we acquired it from.  In raw acquisition, there's no straightforward
 way to do this.  In simplified acquisition, aq_inner.aq_parent is the
 container.  The simplification is the rule (A o B) o (B o C) = A o (B o C).

I don't see how this simplification actually makes a difference...
In what way does it change the search order?
From what I read, I though it just reduced the number of checks you had
to do...

 All of these would search the dotted expression from right to left, so they
 would give you B's I.
  dtml-var expr="aq_context(A.B.C.D).I"
  dtml-var expr="aq_context(A.B.C).I"
  dtml-var expr="aq_context(A.B).I"

cool :-)

 All of these would search the containers of the right-most object, so the
 first two would give you A's I, and the third B's I.
  dtml-var expr="aq_containment(A.B.C.D).I"
  dtml-var expr="aq_containment(A.B.C).I"
  dtml-var expr="aq_containment(A.B).I"

weird ;-S (but I suppose someone might find it useful ;-)

The external methods were very cool. How should I got about petitioning
for 
dtml-var anobject aq_context to become valid syntax?

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 )

Re: [Zope-dev] Acquisition ( slightly less Confusion ;-)

[Shane Hathaway]

Chris Withers wrote:
 How should I got about petitioning
 for
 dtml-var anobject aq_context to become valid syntax?

There's one little (okay, big) problem with this idea: aq_context
strips the security context.  In fact, it could be used to confuse the
security machinery.

Let's say I'm Joe Hacker and I have set up membership at
www.zope.org/Members/jhacker.  I create a DTML method called index_html
with this:

dtml-with Members
dtml-with hathawsh aq_context
  dtml-call expr="index_html.manage_edit('1 0WN U')"
/dtml-with
/dtml-with

Line 2 might be written as dtml-with hathawshdtml-with aq_context.

Now I may have accessed the member folder for hathawsh with the local
roles that are supposed to be in effect only in my own folder.  Zope
acquires the local roles from anything in the path
/Members/jhacker/Members/hathawsh/index_html.  Normally the local roles
would be determined by /Members/hathawsh/index_html, in which case Zope
would find no local roles for jhacker.

"aq_containment" should be fine, however.

Shane

___
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 )