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

[Martijn Faassen]

Jim Fulton wrote:
> >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.

Yes, I understood this point. I was just curious to see what the
future of context wrappers would be -- to make something contained
presumably a decorator can be used, right? Or is this still different
from context wrapping itself? (Is 'ContainedProxy' the name for the
decorator?)

This might mean we can rename 'context wrappers' or even get
rid of them. Being able to rename them away from the word 'context' makes
that word easier to use, as then it cannot refer to both context wrappers 
and containment based context. Or is this still different
from context wrapping itself? I'm looking for opportunities to reduce
conceptual overloading. Ah, I see you saying that context wrappers may
actually go away below, so that question is answered.

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

I was deliberately vague as I have no clear idea. :)

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

I was imagining a bunch of hooks in the container implementation that 
sends events when possible, but just don't break if there are no 
events to be sent. I'm not sure how easy this would be to accomplish.

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

If a decorator is used to accomplish it, could it be enough to find the
event-generating decorator in the Zope context but the non-event generating
one outside the Zope context? I'm not entirely clear on the use cases of
usage of container outside the Zope context.

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

I asked that question to hear more from you than just 'yes' or 'no'. :)

Why is it really true that it would simplify matters if views accessed
their context the same way containers did? Accessing the view's context
is another operation than accessing the containment parent, so why
would it simplify to unify these?

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

If you used self and views have their own containment (based on the
containment of their..classes..?) you'd still acquire, right? 
(and eventually pass through content space) Is it
a common need to acquire through content space directly from a view?
Hm, but I notice I'm reasoning from a perspective where views 
are local. The global case is not quite the same.. Hm.. Okay, 
if views have their own containment in software space, I don't quite
know how this would be determined. :)

[snip]
> > 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,

Okay.

> > It may in fact lead to bugs if it
> >were so.
> 
> Maybe, but I sort of doubt it.

Not when looking up a component, I guess, but when just dealing with
containment separately I can see it leading to confusion when writing
view code. It makes views and content act the same when they're not really
the same. When I want to generate a breadcrumb trail, do I want the view in 
it at the end? I can also imagine cases where I get confused asking for the
parent of the view instead of the content object as I intended.
It is hypothetical confusion, of course. :)

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

Will these be the same as the decorators? I'm not clear on the difference
between the decorators and the context wrappers; are they different?

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

That sounds like a good thing to try.

Lookups happen through containment, but there are also circumstances when
such lookups cannot work. The current fallback behavior is to find
global stuff if context is not present, right? Phillip mentioned somewhere 
that they used to do this in PEAK but that this turned out to be confusing.

Perhaps it would be useful to add another interface to make something
context aware. IContained can be adapted to IContextAware. Views also 
implement IContextAware (but not IContained), and their behavior could then 
be to look for their 'context' attribute as their context.

If something is not context aware at all, lookups simply fail.

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

Okay, understood. Still don't know whether this outweighs the potential
problems of doing it in application code by hand. I hope some kind of
way can be found to automate this.

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

What about the IContextAware interface I proposed above?
That way you could still make views behave that way concerning 
acquisition, but they still won't be contained to the programmer.

Regards,

Martijn