[Zope3-dev] Using parent references rather than context wrappers to represent containment

[Jim Fulton]

Martijn Faassen wrote:
> Jim Fulton wrote:
> 
>>  Issues uncovered so far
>>
>>    A number of issues have been uncovered by the prototype effort to
>>    date.
>>
>>    1. It isn't enough for contained objects to implement IContained.
>>       Containing objects need to manage the '__container__' and
>>       '__name__' attributes.  In addition, containers need to assure
>>       that contained items implement 'IContained', wrapping objects
>>       in contained proxies as necessary.  As with context wrappers,
>>       it's essential that this be done consistently. It's not enough
>>       for a container to satisfy this requirement if one if it's
>>       containers does not.
>>
>>       It appears that 'IContainer' should be expanded to collaborate
>>       with 'IContained'.  At first, this seems a bit onerous,
>>       however, 'IContainer' is already a Zope-specific interface, so
>>       perhaps this isn't such a problem.
> 
> 
> I don't consider this to be a big problem; I wouldn't expect this
> to complicate container behavior a lot overall. If it were to make
> container behavior too hard to reimplement in a fairly straightforward
> way it might become a problem though. Is there any reason to expect
> this?

The issue isn't so much the complexity of implementing the API so much as
the Zope specificity of the API.  Of course, IContainer is already Zope
specific, so this is, perhaps, not so much of an issue.


> 
>>    2. Context wrappers have evolved to provide more than context
>>       management. They provide dictionaries that can be used for
>>       caching. They also provide support for context aware
>>       decoration. When we create a context wrapper for an object, we
>>       do so through adaptation. Specialized adapters for containers
>>       provide support for generating expected events when containers
>>       are modified.
>>
>>       With the move toward parent references, context wrappers are
>>       not used in many places there were used before.
> 
> 
> Would 'context wrappers' still be called context wrappers now? The goal
> of context wrappers is to provide context; if containment is supplying
> this context instead, perhaps we can take the word 'context' out of them?

The primary job of context wrappers is to provide context. Of course,
if an object implements IContained, we no longer need to context wrap it.
We do want to context wrap it if it doesn't support IContained. We might
even be able to use the ContainedProxy for this.

My point is that context wrappers had these second auxilary responsibilities.
If we do away with context wrappers in most cases, we'll need to consider who
will take over these responsibilities.


> 
>> It no longer
>>       seems appropriate to rely on context decorators to ensure that
>>       necessary modification events are generated.
>>
>>       Three posible ways to generate modification events are:
>>
>>       a. Move the responsability for generating modification events
>>          back to applicatin code (views or or adapters used by views).
>>
>>       b. Add the responsability for for generating modification
>>          events to IContainer.  This begins to make 'IContainer' a much
>>          richer interface than might be appropriate. There might be
>>          some interest in using the containment framework outside of
>>          Zope, where requiring Zope's event framework might be a
>>          liability.
> 
> 
> This would be my preference. While supporting outside use is of interest
> I think that this:
> 
>   * does not outweigh the benefits of having well-tested code do this work
>     instead of having to implement this in possibly lots of application code.

k

>   * could be supported by making a base containment system which does not
>     depend on the event system. Zope use would extend it in some way to
>     support the event system, other code might not.

How would you do this?  If I have a class that implements IContainer, and
IContainer says I have to generate some events, don't I pretty much have to
generate those events?  Are you suggesting that I keep two versions of my
class?  Even if I use a mix in, I would need to be able to choose alternate
mix-in classes.

BTW, I envision providing an IContainerDecorator for mapping objects that could
be used to easily implemement IContainer for non-Zope-specific mapping objects.
Perhaps factory definition could include an option to decorate an object during
creation.



> 
>>       c. Continue the use of a decorator model, but decouple
>>          decorating for the purpose of supporting the Zope application
>>          framework from decoration to support context management.
>>
>>    3. It would be useful to unify the context managemnt used by views
>>       and the 'IContained' framework. It would simplify matters if
>>       one accessed the context of a view the same way one accessed an
>>       object's container.
> 
> 
> Is this really true?

Yes


 > Would this simplify matters specifically?

Yes.  Suppose I'm sitting in a voew method and I want to acquire
something. I have to use self.context, not self.  There is some view
code that uses context methods so that it can acquire directly from
self.  If views implemented IContained, they could acquire things
just like regular content.


 > After all,
> looking up the context of a view is not the same as looking up the
> containment of a content object.

Right, but I think it may be close enough.  But there's enough doubt
about this that I think I'll drop this point,

 > It may in fact lead to bugs if it
> were so.

Maybe, but I sort of doubt it.

...

> For redundancy's sake I'll summarize my own position. :)
> 
> To start out, I think that making containment not dependent on 
> context wrappers is a good step that I support. I'll repeat my
> question on the role of 'context wrappers' after this change.

They will only be used when you traverse to something that doesn't
implement IContained.


 > I'd
> like to see a summary of their remaining uses in the Zope 3 code base.

Whenever we traverse to something during URL traversal, we would make
sure that the resulting object implemented IContained. If an object didn't
implement IContained directly, we'd add a context wrapper. At least, this was
my plan. Perhaps we shouldn't do this.  Perhaps I should try *not* doing this
and see what happens. :)


> Is it intended that their implementing the IContained interface is
> a permanent possibility, or will the ability to offer decorators to
> this be enough? I admit I'm a bit confused about the various kinds of
> wrappers involved. :)

It may very well be the case that this change makes context wrappers, as we
know them today, go away.


...


>>    2. Move responsability for generating modification events for
>>       containers back to application code.
> 
> 
> Could you describe your motivation for this choice? I'm curious, as it seems
> to shift a lot of responsibility to the framework user.

The event system is part of the application framework. Content objects
normally don't have application-specific logic.  One might want to use a
content object in an application that doesn't use events.

For other content objects, we generate modification events in application
code because the decision about what constitutes a meaningful modification
of an object is application dependent.


> 
>>    3. Optionally allow vies wo implement 'IContained' and add
>>       'IContained' support to BrowserView.
> 
> 
> I think I disagree with this one. I can't really see the use cases for
> this; could you describe some?

There are a number of views that currently use context methods to gain access
to their context wrappers so that they can acquire things or access the
component system using themselves as the containment context. They could
be modified to work differently.  I agree that the relationship between a
voew and it's context is not strictly a containment relationship. OTOH,
it seems pretty unambigius to me that a view should always acquire things
through it's context, which makes it's context relationship quite similar
to a containment relationship.

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