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
ILedgerSet, name "ledgers"
IJournalSet, name "journals"
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
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.
Zope3-users mailing list