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

Reply via email to