[Zope-CMF] Store development with CMF (new guy)

[sean.upton@uniontrib.com]

> Both.  No application should access portal_memberdata; that 
> is a detail 
> private to portal_membership.  portal_memberdata might not exist, yet 
> applications can assume that members have certain properties, either 
> through the existence of a portal_memberdata tool or directly through 
> the user object.  However, there is no documented way for 
> applications 
> to find out *which* properties are available.  I have not 
> found a way to 
> solve that problem, since user folders provide no common API for 
> property discovery.  Perhaps we need to standardize on the property 
> management API.

Yes... especially if such standardization could have the side-benefit of
informally preventing interface-compliant applications from direct attribute
access.  Direct access to attributes turns out to be problematic for
non-ZODB backends; this could be solved by using Python 2.2+ properties, but
I would prefer to avoid this route for now. As it is now, in order to make
my tools work with applications that try to access properties as attributes,
my portal_memberdata.wrapUser() creates memberdata objects that subclass
PropertyManager, and calls a method to sync the properties with the RDB
values prior to wrapping and returning the member object, and
notifyModified() has to be explicitly called on the member by any skin
method changing the properties to sync the property values back to the RDB
backend - this is kludgy.  Perhaps this problem will go away once I get over
my worries about migrating to Python 2.2 and use properties with custom
set/get, or get time to wrap my head around APE and use the stock tools...

Sean