> 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.
There are two new issues caused by that change:
1.) MemberData factory lookup
CMF 2.2 has a new feature that allows to register customized MemberData
That feature seems to be obsolete in CMF 2.3 because the MemberAdapter
is now responsible for creating MemberData objects and AFAICS using
customized MemberData with an un-customized MemberAdapter doesn't make
Because CMF 2.3 will anyway break customized MemberData implementations
I propose to remove the factory lookup completely in CMF 2.3.
2.) direct MemberData property access
Wrapped users are now MemberAdapter objects. So wrapped users no longer
have attributes like 'email' or 'listed'. This is a security improvement
because you can't bypass the API with its permission checks.
But 'member.email' is more convenient than 'member.getProperty('email')'
and used in many places. I fixed these in CMF itself, it I'm afraid that
change will break a lot of third party code.
I propose to add read-only properties that return the values in a modern
format (datetime instead of DateTime, unicode instead of encoded strings).
Should we support a fixed schema with the default member data properties
or should we use a customized __getattr__ method?
Zope-CMF maillist - Zope-CMF@zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests