[Zope-dev] ObjectManagers and their children

[Michel Pelletier]

gtk wrote:
> 
> >> The children are stored as attributes of the ObjectManager
> >> itself, NOT in a dict. This makes some sense from an
> >> acquisition point of view, but probably means that  there
> >> are a whole bunch of "reserved ids" like manage_beforeDelete.
> 
> > I also feel a little worried that a future version of a class
> > might add a class attribute which clashes with a pre-existing
> > instance attribute added by the user.
> >
> > The protection you describe won't help if the attribute is added
> > in an earlier version, before that class attribute was added.
> 
> Aah, you're right. Well, we could perhaps hack ObjectManager to store its
> kids in a dictionary, but I'm not sure whether that'd break Acquisition.

Not if you did it right.  When ZPublisher traverses a heirarchy of
objects, it looks for objects first with 'getattr' and then with
'getitem'.  So for the path '/X/Y'  It first tries 'X.Y' and then
'X[Y]'.  So it is very possible to create an object manager that stores
its children in a dictionary and defines an __getitem__ method that
returns the children.

In addition, you would need to make sure Acquisition worked right by
having __getitem__ return *wrapped* children; otherwise Acquisition
would fail.  Something like:

  child = self.children[name]
  return child.__of__(self)

(The last line can be read "Return child *in the context of* self").

That's the theory.  Way back in the day, a few months ago, I tried to
write a BTreeObjectManager that stored it's children in a dictionary (a
BTree, but it acts just like a dict and it's faster and much more space
efficient when working with ZODB).  I got pretty far along, and it
seemed to work ok, but there were bugs I never had time to fix.  It was
just an experiment.  if I can dig up the code, I'll post it.

-Michel