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.
- 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.
- 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.
Zope-CMF maillist - Zope-CMF@zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests