[Zope3-dev] Context and Component Lookup

[Phillip J. Eby]

At 12:40 PM 8/7/03 +0200, Martijn Faassen wrote:
>Phillip J. Eby wrote:
> > I am saying there should be "freedom of choice" (objects that do lookups
> > can choose where they want to look up from) but no "invasion of privacy"
> > (other objects should not have the ability to reroute an object's lookups,
> > unless they are the object's owner or context, or have been explicitly
> > delegated this responsibility in some other way).
>
>I think that this is a good principle. Such freedom of choice (choosing
>to look up in your own context or some caller's context) is easy to
>accomplish if contexts are passed along explicitly. You simply pick
>the right context to do the lookup on (context passed by the caller or
>your own).
>
>Requiring an explicit context passing however places a heavy burden on
>components that Jim would very much like to avoid. One of the basic
>goals of Zope 3 is not to burden the developer with a lot of
>Zope 3 specific rules when developing a component.

Note that after containergeddon (if I understand it correctly), *all* 
objects can be considered to have a context; it's just that objects that 
don't care about their own context will have "global context".  So, it's 
not that there will be a requirement to pass around separate "context 
objects" or for every method handling an object to add a context to it.


>(considering the DOM it looks like it may be useful to considering adding
>some flexibility Zope 3 so that I can tell it somehow that it should use
>parentNode for context lookups, not the default __parent__ or whatever
>containergeddon is using. On occasion 'traditional' context wrappers may
>actually be the easiest thing to use and we may be able to tell Zope to use
>those too in some way..)

In PEAK, the parent component is accessed with a getParentComponent() 
method; if an object doesn't have this method, we attempt to adapt it to an 
interface that has the method.  I don't know what's planned for Zope 3, 
here.  PEAK doesn't do context-sensitive adapter lookups in the general 
case; instead, we adapt to context-sensitive *interfaces* when context is 
relevant.  This means we're free to adapt objects to determine their context.

As Jim pointed out, for Zope 3 to do this would imply that any adaptation 
of e.g. DOM nodes to contexts would require global registration of the 
adapter.  I'm not sure how big a deal this is.

(Interestingly, in earlier versions of PEAK, there was a global place to 
register things, that was used by default if an object didn't have 
context.  We later decided to rip this out, because it was better to get an 
error if you tried to look up something that couldn't be found in your 
non-existent context, than have things work, but with perhaps the wrong 
configuration because your intended context was missing.  I don't know if 
this will also be the preferred approach for Zope 3.)


>I'm coming at this from a position of ignorance compared to you two, but
>perhaps it's useful as some outside input from a developer not as steeped in
>all this. Though of course I've struggled endlessly with context issues in
>Zope 2, so I'm not exactly a good example of a completely ignorant developer.
>:)
>
>Anyway, from my semi-ignorant perspective, I do find myself agreeing with
>Phillip a lot in this discussion, and I worry a lot about the encapsulation
>breakage Jim's proposal implies.

It might just be that we agree because we're both ignorant.  ;)  I've 
worked with PEAK's CA a lot more than Z3's, as 'zope.publisher' is the only 
part of Zope 3 I'm really using at the moment.  But, I do bump into the 
Z3CA at the edges, and I'm worried about what impact the call-context 
proposal might have on the parts I *do* encounter.