yuppie wrote:
> 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.

Done: http://svn.zope.org/?rev=120512&view=rev

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 
factories: https://bugs.launchpad.net/zope-cmf/+bug/377208

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 
much sense.

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

Reply via email to