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

[Martijn Faassen]

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?

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

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

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

>        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? Would this simplify matters specifically? After all,
looking up the context of a view is not the same as looking up the
containment of a content object. It may in fact lead to bugs if it
were so.

>  This would avoid the need to put context
>        wrappers around views.
> 
>        Right now, we require views to provide a context attribute.
> 
>        We could:
> 
>        a. Optionally allow views to implement 'IContained'.
>           We could encourage this, for example, by modifying
>           'BrowserView' to implement 'IContained'. Views would still
>           be required to provide a context attribute.
> 
>        b. Require views to implement 'IContained'.  At this point, it
>           wouldn't make sense to require a 'context' attribute.
> 
>           If we do this, does it makse sense to name the attribute
>           '__container__'?   Would '__parent__' be better?
>           '__context__'? Would we need to rename the the assiated ZPT
>           variable?

I think 'context' for view is a good word. This does not mean we can't
use some other word for the parent of the containment relationship.

>     4. The attributes defined by 'IContained' need to accessable
>        through security proxies.  I think that these attributes should
>        be unconditionally accessable in all objects.
> 
>   Comment desired!
> 
>     I'd really like to get comment on the issues above.  Absent,
>     comment, here is how I'm thinking of resolving these issues:

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. I'd
like to see a summary of their remaining uses in the Zope 3 code base.
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. :)

>     1. Add responsability for collaborating with 'IContained' to
>        'IContainer'.

Agreed.

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

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

>     4. Modify the security framework to allow access to
>        '__container__' and '__name__'.

No comment here; I'll just trust you on this. Jim is trusted code in my
security framework. :)

Regards,

Martijn