[Zope3-dev] Context and Component Lookup

[Jim Fulton]

Phillip J. Eby wrote:
> 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,

Why? I submit that it is easier to reason about, because there is only
one site that contributes components.

(FWIW, I can see your point and have some sympathy for your point of
  view.)

 > and too easy for one application context to
> "pollute" another and break intended invariants. 

That can happen in either case. If I use an object from another
site with it's components, those components might break my invariants,
or my site might not provide an adequate environment for them.

I should point out that I'm less concerned with sharing of objects
across unrelated sites. That just seemed like a simpler example.
A more realistic example is one where I have say site S1 and site S11,
such that site S11 is contained in site S1.  If I'm in S11 and I use
an object from S1, I'd like to use components defined in S11, if,
and the other way around.

 > A content object
> should have one and only one "place".

It does. I'm not convinced that that should be the sole basis for finding
components, especially given that many objects don't have a place.

...

>> 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.

Sure. That's just an example. The point is that there are many components
that don't have containment information, many of which don't really have
a place.

> 
>> 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. 

If the object is a method return value we have no place to suggest.


 > This can be done in the presentation-level code, similar to
> how you do context wrappers now. 

No, because the component lookup may be far removed from the
presentation code.

 > I mean, you're presumably going to
> have an 'IContainerAware' or some such, right? 

Sure, but most objects won't implement it.  I don't want to *make*
objects implement it soley to use the component architecture.

Objects that don't implement it will in some cases (e.g. when they
are added as an item of a container) have proxies put around them to
provide them with the information, but methods of the proxied objects
won't have access to the proxy.

 > 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.

This just isn't practical. I speak from experience.  For an object to
use context, it needs special DNA, which is OK, but I'm not comfortable
requiring special DNA to work with components.


> 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? 

I agree, but should context awareness be a prerequisite for working with
the component model? I suggest not.


 > 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. 

That works great to the extent that we get to objects via traversal, but
traversal isn't the only way to get to objects. We often get to objects
via method calls. We have been forced in many cases to make the methods
wrap their results.  This is a lot of bother.  It significantly slows
development. Worse, developers usually don't understand why it's necessary.
Something doesn't work, so they look into their book of incantations.  The
book suggests that maybe a context wrapper will work, so they offer one up.
To them, it's a dead chicken.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (703) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org