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