Hi!
MemberData objects are currently persistent objects for storing member data *and* wrappers for user objects. I propose to split this up into a persistent MemberData object that is just used for storing member data and a new non-persistent MemberAdapter that provides all the methods currently provided by MemberData objects. MemberAdapter would be a multi-adapter for IUser and IMemberDataTool. self.__parent__ would be the user folder. Pros: - The member objects can easily be customized without replacing persistent MemberData objects. - Users from different types of user folders can get different adapters. No MemberData objects are needed if the user (or user folder) can store the member properties. (Adapted is the user, so the user's interface has to indicate the capabilities of the user folder). - For some methods like changeOwnership() AccessControl expects that the parent of a user is the user folder. MemberAdapter will have the same parent as the original user object. - There is no need to migrate persistent objects. Cons: - The API of customized MemberData objects will no longer be available. The customized API has to be moved to a new adapter. - Code that expects the user object or the member-data tool in the aquisition chain of members will no longer work. - Code that bypasses setProperties/setMemberProperties and getProperty methods of members will no longer work. If there are no objections or better ideas, I'll implement that on the trunk. IUser is only available in Zope 2.13.2+, so I'll have to make that Zope version required for CMF trunk. Cheers, Yuppie _______________________________________________ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests