[Zope-dev] Schizophrenic ObjectManager?

[Clemens Robbenhaar]

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