[Zope3-dev] Re: Context proposal II

[Jim Fulton]

Martijn Faassen wrote:

...

> I still don't like the
> request's context used for all lookups unless specifically overridden in
> the code.
> 
> In particular, Phillip has been asking for use cases motivating the
> proposal. I have seen few so far and I agree with him that we need some more..

I've given two:

- Looking up components for objects that don't track containment
   information.

   It is not acceptable to me to make containment management a prerequisite
   for component usage. It is also not acceptable to me to fall back to
   global component registries when no context is available, as is done now.

- When using components from a different site, I want the use to reflect
   local customizations as long as those customizations don't break
   the invariants of the used objects. If a used object has depenncies on
   specific instances or on it's specific site, it should provide an adequate
   context so that invariants are met.


...

>   * Jim feels that there is no problem with the request's context determining
>     the lookup context of all the components which are used.


No. I've acknowledged that sometimes components have dependencies on
their containing site. In these cases, the components should supply
a containment context when they look up components that have to come from
their site,

 >     Since the
>     components are looked up by interface the right functionality is still
>     found, even if it is isn't coming from the containment context at all.

>     I've put up a few 'data dependency' use cases up in the original
>     thread as counter arguments. Instances completely flexibly connected
>     with respect to their interfaces can still be dependent data-wise.
>     For another argument, this time based on human imperfection, see the 
>     third point.

In most cases, components depend soley on interfaces. Sometimes
a component must always be connected a another specific component.
In this case, a permanent connection should be made. (Fortunately, containergeddon
will make this easier.)  Sometimes, has a requirement that it always interact
with a specific site. In this case, a specific context should be provided for
lookups.

Examples of these kind of dependcies can be found in the component registration
machinery through the web site management, When a registration object changes it's
activation status, it *must* interact with services (registries) defines it it's
site alone.  In this casem it actually uses acquisition APIs rather than
component lookup APIs because falling back to a containing site isn't
acceptable.  A registration object registers a specific component and has
a direct reference to that component. It doesn't use component lookup
to access it.

> 
>   * If you use a component in another site, this means that your own
>     site's context should provide all the components this component
>     tries to look up (and recursively onward).

Right

 >     Jim states that
>     having to satisfy these criteria won't be a problem in practice.

Because in most instances of this, the using site simply customizes
the source site.  Usage if components accross unrelates sites will be
extremely rare IMO.

..

>  *  If there are problems then the code you're using is actually 
>     misbehaved with respect to component lookup and use and you shouldn't be
>     using it that way at all. Jim says they're "wild animals" and I
>     should forget about using them.
> 
>     My worry here is that we're actually making simple use much
>     harder than it should be.

I don't think that sharing objects accross unrelates sites is simple
usage.


 >     Jim argues that code is flawed if it depends on
>     a particular instance implementing an interface and cannot use
>     another instance implementing its own interface. I disagree
>     (first point).

I don't know what you just said.  I have no idea what you are asserting
that I'm arguing.

>     Anyway, even if I'm wrong and Jim's right here,
>     I still think I can make a case that I shouldn't be stopped
>     by the system from using such flawed code. It is hard to get
>     really flexible code right. It is much easier to make
>     tighter connections. In practice much code written is flawed in that
>     it has reasonably tight interdependencies. Note that this code is not
>     buggy; it works just perfectly within its own context. It's just broken
>     when supplied with other contexts. 

You will be able to make connections as tight as you want them to me.
Containergeddon will make this much easier and cleaner.

>     Since mere mortals like me will be writing Zope 3 application code,
>     Zope 3 application code will likely contain such dependency
>     flaws as well. In Jim's proposal, the system would seem to stop
>     the developer from calling into any such code from outside its own context.
>     I am worried that this is a hindrance.

If code has such tight dependiencies, it should reflect the dependcies in it's
implementation. If you aren't sure, always supply the context.

>     Sometimes being able to use horribly flawed code is better than not 
>     being able to use any code at all. In Jim's proposal it seems to me 
>     that the only thing left to do when you want to use a 'wild animal' is 
>     to forgo Python method calls and instead use the publisher machinery, 
>     starting up a new thread as the context is thread-global..

I sugges that you simply not do this. There are going to be objects that
expect tehir usage environment to provide what they need. If you use them
and don't provide what they need, you lose. I really don't see a problem
with that.


>     I'm worried also that this will affect scripters. Calling
>     methods on objects in some other container is not that rare.

No, calling methods on objects in other *sites* is.


>     This other container may be a site by virtue of having its own
>     components installed (adapters, etc). Those adapters won't be
>     used though if called from within another container. Does this
>     mean that the scripter somehow has to deal with the reason why?

Maybe the scriptor shouldn't do that. The scriptor has to rely on some sort
of common facilities.  They shouldn't use facilities that aren't available
for the object's they are using.

Jim

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