[Zope3-dev] zwiki: performance of findChildren()

Roché Compaan roche@upfrontsystems.co.za
Wed, 23 Apr 2003 08:37:47 +0200


Hi Jeffrey

> http://mail.zope.org/pipermail/zope3-dev/2002-January/000407.html
> 
> Note: in that message, I mentioned a Zope/CMF app that needed 
> relations.  I don't think mxmRelations existed at the time, so I ended 
> up writing my own relationship manager and event framework.  This ended 
> up putting me so far behind schedule (fortunately it was just an 
> internal-use system) that it was the nail in the coffin for this whole 
> project, which is still a bitter taste in my mouth.  So, I apologize if 
> I come off a bit offensive about this issue.  It's the one wall I crash 
> against more often than any other.

I'd love to know what the caveats you ran into were. We built a
relationship manager around mxmRelations and so far it has given us a
lot of joy. It is still early though and maybe the problems you ran into
can help us steer around them.

Briefly, this is how we put it together:

For each class we define an _relations structure similar to _properties
used by the PropertyManager that is a list of mappings specifying the id
and cardinality of the relationship:

    class Person(<zope classes>, RelationsAware):
        _relations = (
            {'id': 'Organisation', 'cardinality': 'single'}
            {'id': 'Address', 'cardinality': 'multiple'}
        )

During product initialisation all class relations are registered with a
relations registry. As soon as you add an instance of the product
through the ZMI a folder named 'relations' is created containing an
mxmRelation for each relation:

    relations
        |
        +------ Person_to_Organisation
        |
        +------ Person_to_Address

All of the classes that want relations, subclasses 'RelationsAware'.
This gives the class 'manage_addRelations' and 'manage_editRelations'.
Both these methods take the REQUEST or a mapping as parameters and will
pick out keys that match ids of relations defined in _relations. The
value for a key is a path to the object that we want to relate to.
'manage_addRelations' and 'manage_editRelations' finds the
appropriate mxmRelation and relates/unrelates objects when called.

Finally we defined __bobo_traverse__ on RelationsAware that resolves
related objects on each class. This makes references like
Person.Organisation.Name (or Receipt1.purcharser.name in your case)
possible.

-- 
Roché Compaan
Upfront Systems                 http://www.upfrontsystems.co.za