[Zope3-dev] Context and Component Lookup

[Phillip J. Eby]

At 02:26 PM 8/7/03 -0400, Jim Fulton wrote:
>Martijn Faassen wrote:
>>Perhaps I'm just completely missing the point, but I see difficulty
>>both with this, and with the requirement that I suddenly need to supply a 
>>lot of components that my site doesn't directly deal with,
>>just in order to use a different area of the system.
>
>Sometimes, it just doesn't pay to try to do this.  It may be, that I'll be
>unable to use an object from another site if that object:
>
>- Has things that it expects to have met by the using environment, and
>
>- I can't meet those needs.
>
>Sometimes, you just can't keep a wild animal as a pet. :)

My take on all this, is that the idea that I'd want to adopt a wild animal 
in the first place is bogus; the normal use case is to either 1) purchase a 
domestic animal (instantiate a component for my private use), 2) enjoy the 
wild animal in its natural habitat (accept that the borrowed component will 
keep to its natural roots), or 3) go the zoo, which has specifically 
exported certain characteristics of the animal for my enjoyment, while 
tending to its other needs.  :)

To translate back into component-oriented terms: I should not expect a 
component that is part of some other component to be customizable to my 
needs, unless I plan to remove it from that context and supply it with a 
new one.  Just as I don't expect to use the battery from my cellphone to 
power something else while it's still in the phone, unless the phone offers 
a power output jack for this.  I must accept the constraints placed on 
configurability of a component by what it is connected to.

While in principle the customization you've suggested might be possible for 
some component usages, I think that reasoning in terms of physical objects 
is easiest for most people, and the additional flexibility is not worth the 
added conceptual overhead to understand what's going on.  I do not expect 
to be able to -- or be required to-- supply configuration to things that 
are part of other things.  I do expect to be able and required to do so for 
things that are part of a thing which I am assembling.  This is how 
physical components in the real world seem to me to behave.


>I guess it really boils down to what you want to do.  If an object really
>needs things that are only found in it's place, then it should supply an 
>explicit
>context when it looks things up.
>
>I think that, in practice, this won't be such a problem.  Despite my original
>proposal, I don't think there will be much sharing accross unrelated sites.
>When sites are related, designers will arrange for the necessary components
>to be in place for sharing to take place.

I'm still curious about what the real use case that motivates this is, 
because I'm having trouble envisioning why I'd want to 1) borrow somebody 
else's component, while 2) knowing what configuration it needs for my 
purposes, and that the desired configuration differs from what its context 
supplies, and 3) prefer to still use it anyway, instead of just installing 
a similar component in my own scope.

If we're talking about a view using content from another context, I think 
the content should lookup content in its own context, and the view should 
look up views in its context.  But that's the only scenario I can think of 
where those three conditions seem to apply.  All this A and B and S1, S2, 
S11 stuff is a little too abstract for me.


>I suppose so. But if you are using the other assemblage, doesn't it already
>have one it needs for it's own requirements? You'd be typically building a
>single site by composing these and other assemblages.

Which is why I don't get why you'd want to substitute such on your own 
behalf.  Adapters that *you* need, on the other hand, are reasonably 
something you might desire to supply, or expect your context to supply.


>>Imagine there's a site X, which contains objects. It somehow has a need
>>for a count of those objects, and looks up a service which maintains this
>>count.
>>Now I have a site Y, which uses facilities in site X by calling into
>>it. I have to supply a version of the counting service in site X. But
>>this version of the service won't have the correct count.
>
>So you are accessing some facility that depends on the count.  So, let's
>say the job of this facility is to generate a count report.  There are
>2 possibilities:
>
>1. The facility generates a count report for the place it's used.
>    In that case, it will report Y's count and it's doing it's job.

Sure.  But it's a rather poor component if it's not documented that that's 
what it does, and/or there's no way to tell it whose count you want 
reported, as either a method parameter, attribute, or whatever.