Just to be sure I understand, I think you meant to use the word "relationship" instead of "relation" throughout this message. Max M wrote:
If an object needs to be related to another object, there is no need for any of the objects to know they are related. If all the relations are external to the objects you can relate objects that are not programmed to be related. Keeping all the relation code loosely coupled from the objects.
Making the objects hold the responsibility for the relations means that all objects has to take it into account. There is no reason for that. To take a simplified example from Plone.
relations/ members_groups
Members/ Groups/
In this case I can make the "members_groups" relationship manager take care of the relations, and Members and Groups would not need to know they can be related. I don't have to change the code in Members at all. Thus leaving Plone as it is, while I can add group functionality.
maxm_groups = context.relations.member_groups.get(context.Members.maxm)
The other way around I would need to change the Member product, adding group relations, and I can risk all hell breaking loose when Plone is updated the next time.
I wonder if any of you guys reinventing relationships has even bothered to try out the mxmRelations product? You are taking the long and winding road to get to the same conclusions I did a year ago ...
I don't know about the others participating in this thread, but I'm reaching quite different conclusions than you did. For example: - The solution should not require Zope. - It should not be necessary to visit the management interface to set up relationships. - Developers should have the *option* of using relationships directly in their classes, with a Pythonic API. I listed other requirements this morning, and as far as I can tell, few are fulfilled by mxmRelations. On the other hand, maybe I misunderstand mxmRelations. Does it fulfill the requirements I listed? I'm sure there's nothing wrong with mxmRelations, but it seems like we're targetting different audiences. Shane