ILocation rather than IContained? (was Re: [Zope3-dev] Using parent references rather than context wrappers to represent containment)

[Jim Fulton]

Martijn Faassen wrote:
> Jim Fulton wrote:
> 
...

> Yes, I think there's a tension between this requirement and debuggability
> here. Context awareness can be added to existing objects using a decorator
> or adapter though, right?

Sure, that's what context wrappers do now, however, direct references are
far more debuggable than than wrappers.

Note that views currently have duplicate references to the thing they view. They
have the context reference in the context wrapper around them and they have their
context attribute.

 > Container awareness I agree should not be a requirement
 > for the component architecture, but a form of context awareness (that
 > can be added using a decorator if the object itself does not support it)
 > seems to be essential conceptually, as this determines where the lookups take
 > place.
 >
 > One could explain this by saying that *any* python object can be
 > adapted to IContextAware. If a python object does not specify context
 > awareness itself, Zope adapts this to a IContextAware implementation
 > that returns the global context.
 >
 > If I instead want a warning or error when my object is not in any context,
 > I could configure matters in such a way that my objects are adapted to an
 > *empty* context if nothing can be found based on a container check, not
 > the global context. This way I could get my error.

It would be nice to manage context and name for views without resorting to
decorators.  I can't help but think that there's some idea that, like
"context awareness" that is as narrow as possible but that does encompass
*both* containment and adaptation relationships. We aren't comfortable calling
adaptation containment, but the two concepts are very closely related.  I think
we are comfortable treating them the same way wrt acquisition and url computation.

One of the things I like about containergeddon is that it makes containment
a foundational mechanism on which other things are based.  I'd like to get to
the point where we don't need the component architeccture to reason about
location.  I'd like to get to the point where many of these computations
can be done directly.  I think that adaptation is equually as foundational.

Can we identify a relation that is the of the container and adapted
relationships? Ultimately, this is about a standard organizational hierarchy.
Perhaps rather than IContainer, it would make sense to have something like:

class ILocation(Interface):
     """A location in the standard object *hierarchy*

      The location can be either a physical location for content objects or
      an adapted location.  An adapter, like a view gets a location from the
      physically located objects that it directly or indirectly adapts.

      From the location information, a *unique* path can be computed for an
      object. By definaition, an object cannot be at to locations in a hierarchy.
      """

      __parent__ = Attribute("The parent of an object")

      __name__ = TestLine("""The name of the object within the parent

                 This is a name that the parent can be traversed with
                 to get the child.
                 """)

The idea is that ILocation is the union of *a* physical hierarchy
and adaptation.  Persistent objects have a physical location. Adapters
have a location based on the persistent objects that they adapt.

Note that a system that didn't use a file-system metaphor could conceivably
use some model of physical location other than containment.

Also note that that even in Zope we want to use something that is a little
more than containment. For example, technically, a site doesn't strictly contain
it's site manager, since the site manager is outside of content space. Put
another way a __container__ need not be an IContainer and, even if a
__container__ is an IContainer, the thing with the __container__ attribute
that points to the container need not be *in* the container.  The physical hierarchy
is slightly bigger than the containment hierachy. The containment hierarchy is
a subset of the physical hoerarchy.

I think that location is a better concept than containment. It is narrow enough not
to get confused with other sorts of associations between objects but is broad enough
to include adaptation.

Thoughts?

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