Re: [Zope3-Users] Multiple containers in one object - how to implement in Zope3?
Is this much different from a folder containing either ZPTPages or Folders (not to mention other things)? Have you thought of filtering the views that show lists of one or the other types? for name, object in folder.items(): if IType1.providedBy(object): ... Cliff Alek Kowalczyk wrote: Hello, I have a simple (on the first sight) problem, which I don't know how to resolve in zope3'ish way. I have a single object, which can contain many objects of 2 another types (IType1, IType2). My intention is to have those objects contained in separate collections (because they are very different 2 types of objects and should not be mixed in one collection) I'd like to have each collection editable like Zope folder, i.e each collection to be IContainer/BTreeContainer. I tried to use the following pattern (which would be natural for pure python or C++ - i.e. two Dicts or two std::mapstring,Type1/2 objects): class IMasterObject(Interface): objects1 = Object(schema=IObjects1, title=uObjects of IType1) objects2 = Object(schema=IObjects2, title=uObjects of IType2) class IObjects1(IContainer): pass # + constraint to have only objects implementing IType1 class IObjects2(IContainer): pass # + constraint to have only objects implementing IType2 I have implemented a simple view and created proper ObjectWidgets - no bigger problems there. But web interface, after creating MasterObject, shows only empty fieldset for objects1 and objects2 fields in MasterObject instance. I don't know how to achieve displaying Container view in those fieldsets instead of Edit view. I have the following questions: - Is this the proper way to implement an object containing two different containers/collections of objects and still use 'folder-like' web interfaces for adding/removing/viewing those collections? - If yes, how to display Container view in those fieldsets instead of Edit view? - If not, how would you suggest to implement this pattern (or its functional equivalent) in Zope3? It seems to be pretty common pattern but I couldn't find a solution anywhere in the book or on the net, so I suspect I was looking for wrong solution and this should be realized in very another way in Zope3... Best regards, Alek Kowalczyk. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Multiple containers in one object - how to implement in Zope3?
Alek Kowalczyk wrote: Florian Lindner napisaĆ(a): Am Samstag, 1. April 2006 15:15 schrieb Alek Kowalczyk: I have a single object, which can contain many objects of 2 another types (IType1, IType2). My intention is to have those objects contained in separate collections (because they are very different 2 types of objects and should not be mixed in one collection) I'd like to have each collection editable like Zope folder, i.e each collection to be IContainer/BTreeContainer. why don't just create two subfolders (of type zope.folder) in you Container object, one for IType1, one for IType2? Good idea, thanks! In the meantime I have made something similar, i.e defined two more container types (IObjects1, IObjects2) and created one IObjects1 and one IObjects2 in the IMasterObject's (which now is also a IContainer) constructor . But now the new question follows: how to limit cardinality of items? I want now to have one and exactly one IObjects1 and IObjects2 instance in IMasterObject. Is there some type of constraint defined, similar to ItemTypeConstraint, for limiting number of elements of specific type, or I should do it on my own by overriding __setitem__ and other methods? Alek, I do the same thing for a complex container with a fixed set of member sub-containers. IVenture(RUSH) ILedgerSet, name ledgers ILedgers ... IJournalSet, name journals IJournals ... http://sample.com/ventures/RUSH/ledgers/CASH http://sample.com/ventures/RUSH/journals/CHECKING The way to get what you want is to make IMasterObject *not* an IContainer but an IReadContainer. There are IWriteContainer and IReadContainer which are sub-interfaces of IContainer. This way no one can ever add/remove those sub-containers. And (presumeably you're doing it now) you add those the instances of Objects1 and Objects2 at creation time of MasterObject, and then never again need to manipulate them. You should also place Container/Containee constraints on the IObjects1 and IObjects2 so they cannot be created in inappropriate places, and of course omit their menu entries from the ZMI so they are not manually addable. -Jeff ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users