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
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
