[Zope3-dev] Context and Component Lookup

[Phillip J. Eby]

At 12:11 PM 8/6/03 -0400, Jim Fulton wrote:

>>Conversely, for anything that's not presentation-based, shouldn't a 
>>component use its containment context for lookups?
>
>That's the question.  I'm suggesting that components should use a
>context that's decided by the application.

Ah.  Okay, if we're talking about non-presentation components -- and 
assuming I understand this correctly -- then I strongly disagree, on the 
grounds that it makes it difficult for a developer to reason about the 
behavior of a component, and too easy for one application context to 
"pollute" another and break intended invariants.  A content object should 
have one and only one "place".


> > To do otherwise would seem to me to negate the whole point
>>of containergeddon: that content components have a fixed containment context.
>
>The problem with this is that there are lots of components that don't
>get a containment context even after containergeddon.  A good example
>is exceptions. These are completely placeless, yet, when we view them,
>we want to use views from the site in which they occurred.

And the code that catches the exception doesn't know what site that 
is?  IPublication.handleException() has access to the request, certainly.


>Similarly,
>components may be computed and returned from a method. These also are
>effectively placeless. Even values that are stored might not get a containment
>context because the objects that store them don't bother to set a context.

So adapt them to a context interface, and "suggest" to them a parent 
component.  This can be done in the presentation-level code, similar to how 
you do context wrappers now.  I mean, you're presumably going to have an 
'IContainerAware' or some such, right?  You just need a way to "suggest" to 
such an object what its containment is, if it doesn't already know, and 
have an adapter that can adapt anything to that interface.  And, the 
adapter needs a __conform__ that adapts the thing it wraps.  Now, you can 
convert the container-awareness adapter back to any other interface you're 
looking for.

Of course, such unaware objects can't *themselves* look anything up by 
their context...  But why on earth would they need or want to?  I mean, if 
the object needed to do lookups in its context, wouldn't it mix in some 
awareness?  Conversely, as long as your traversal mechanism adapts objects 
to container awareness, and "suggests" to them where they were retrieved 
from, then an aware object will "imprint" on the first context it's used 
in.  In peak.binding, IComponent.setParentComponent() has a 'suggest' flag 
that indicates whether this is just a "suggestion" in case the component 
already knows its parent.  There's also a utility function, 
suggestParentComponent(), that adapts an object to IComponent and then 
calls setParentComponent() with suggest=True.