[Zope3-dev] Re: ObjectHub should change data structure

[Paul Winkler]

On Fri, Jun 27, 2003 at 10:58:34AM -0400, Jim Fulton wrote:
> Let's look at the pros and cons of using parent references instead of
> context wrappers:
> 
>   Pros:
> 
>     o Much simpler and much more Pythonic
> 
>     o Object references can be direct.
>       This is a big deal.
> 
>   Cons
> 
>     o Requiring all objects to manage their parents
>       would be intrusive.  Zope 3 wants to avoid any
>       requirements on content objects.
> 
>       <wave member="hands">
>       Perhaps this could be mitigated by permanent
>       decorators.  Such decorators might even be
>       used to avoid mixing in persistence in some cases.
> 
>       That is, when we add an object to a container and the
>       object isn't parent aware, we put it in a decorator that
>       is and we store the decorator in the container.
>       </wave>

That's a nice bit of hand waving :)
I don't have a deep understanding of context wrappers,
but this permanent decorator idea sounds quite simple
and transparent for the application developer.

>     o We'd sort of like to allow an object to be able to
>       have more than one parent.  OTOH, while I'd like to
>       to be able to do so in theory, it is generally
>       inconvenient in practice.

ugh, yes. 

>       For example, synchronizing to the file system is an
>       important feature. 
(snip)

Retaining sanity in the ZMI is an important feature too :)
I'm not sure how this multi-parent thing could be used in software
space, or what you were imagining multiple-parents would be used for.

but I could imagine *thinking* I want it - and being confused by it -
in content space. E.g. we have several sites, served by one zope,
that duplicate some entire pages, and also share lots of bits of
boilerplate text.  I guess multiple-parents might be
useful for implementing a solution, BUT if a content object appears 
in two places, A and B, I probably need to know that when 
I'm editing it in either place. Otherwise I could unwittingly 
specialize the content for context A and make it incorrect in context B.
if A/foo and B/foo are really the same object, I have no way to 
identify that crucial characteristic of them. So I *don't* really
want them to be the same object.

An aside about the zope 2 solution I've designed: I'll create a special 
type of object called a ContentProxy which, for editing, provides a link
back to its source object, but when viewed by a 
site visitor, appears indistinguishable from the source.  
I'm adding managment UI widgets that let you know what pages 
will be affected by editing any given source.  The hardest part 
of implementing this in zope 2 is keeping things correct when 
objects move or change; max M's relations manager should help. 

>       Synchronizing a non-hierarchical object system to
>       a hierarchical file system introduces lots of complexity.

sounds like a don't-do-that-then :)

>     o Parent references introduce circular references

why? how would would you create a cycle? I assume you'd do this
by accident, but I don't see how :)

-- 

Paul Winkler
http://www.slinkp.com