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.

    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 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.

Zope3-users mailing list

Reply via email to