Hi Ian,
Now, I want to have it also contain objects of type 'B', but displayed and managed through a separate tab in the ZMI. If I click on the "Contents" tab of an instance of F, I get the list of contained A-type objects, with cut, copy, paste, delete, etc. If I click on another tab named, say, "OtherStuff", I want to see exactly the same kind of contents-list management page, but for contained B-type objects.
I'm thinking that I might try having F contain an instance of ObjectManager as a property, and delegate all B-managing functionality to that. Management of A would be handled through F's inherited ObjectManager behavior. What concerns me is that the "encapsulated" second ObjectManager wouldn't have a container in the usual way, and that could seriously mess up acquisition.
Another possibility is to maintain only one collection, but to create the illusion of two separate collections by having two copies of the contents ('manage_main') page, each modified to display only one kind of child.
The second alternative works, but You need to maintain two separate copies of the "manage_main" DTML form the ObjectManager ... currently Silva does exactly this (except it filtered out some objects by the id, not the type). The downhill is that one has to maintain the copies from the ObjectManagers DTML, which is not very difficult, but may create some dependency to the used Zope Version. We have not found a better stable, reliable solution so far. An alternative I am currently testing is to have two special attributes emulating the ObjectManager to the 'manage_main', as You propose in the first alternative. However You are right: this messes up management of the ObjectManager items with acquisition ;-) The trick is not to use a full ObjectManager attribute but only something that looks like an ObjectManager to the manage_main, but does nothing otherwise. Thus it does not get messed up too much as the object cannot do a lot. Currently "manage_main" only uses the "objectItems" method, so I try only to override this. The result looks like: class ObjectStub(Acquisition.Implicit): " a stub filtering out objects of a certain type " def __init__(self, meta_type): self._my_meta_type meta_type def objectItems(self): return [ x for x in self.aq_parent.objectItems() \ if not x[1].meta_type==self._my_meta_type ] # manage_main will use 'objectItems' from this object # acquire the rest from the parent manage_main = ObjectManager.manage_main class MyContainer(ObjectManager, ....): " special container class for A and B objects " all_meta_tpes = ('A','B') # list object of type "A" object_stub_a = ObjectStub('A') # list object of type "F" object_stub_b = ObjectStub('B') def manage_main(self): " list only A objects " return self.object_stub_a.manage_main() def manage_main_b(self): " list only B objects " return self.object_stub_b.manage_main() manage_options = ObjectManager.manage_option + \ ({'label':'Contents B', 'action':'manage_main_b'}) + \ ... other tabs here Sure there are some missing security declarations, (at least manage_main_b is public ;-) Also its not exactly my implementation, so it may contain some typos when I have "translated' it from my use case. I am not sure if this is really a good idea, however. This avoids copying around a pretty involved DTML file, but it seems to create even more subtle dependencies ... e.g. it will certainly break when mix in OrderedSupport (from 2.7, I have tested the snippets above only with 2.6.4) Another drawback of either the approaches is that after evert action (rename, copy, etc) one ends up in the contents tab listing A (because this is the manage_main), even if remaining, copying, etc in tab B. I do not know if it helps, but maybe its at least entertaining ;-) Clemens