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

[Eric CESTARI]

Thanks !

So basically, I have to reimplement the MemberData and MemberDataTool=20
to decorate the users from the db and replace the portal_memberdata=20
with my own, right ?

Eric

Le mercredi, 28 mai 2003, =E0 17:13 Europe/Paris,=20
sean.upton@uniontrib.com a =E9crit :

> This, IMHO, is underdocumented, and I want to put together some
> documentation.  Please feel free to ask questions of me along the way=20=

> if you
> choose this route - I intend to write a howto on this to post on=20
> Zope.org.
>
> Sean
>
>> -----Original Message-----
>> From: Eric CESTARI [mailto:eric@ohmforce.com]
>> Sent: Wednesday, May 28, 2003 6:16 AM
>> To: sean.upton@uniontrib.com
>> Subject: Re: [Zope-CMF] Store development with CMF (new guy)
>>
>>
>> Thanks for all the precious input.
>> I have worked on this today, and I guess I will do it Sean's way ...
>> I can't change my database schema and will have to access existing
>> attributes.
>>
>> Eric
>> Le mercredi, 28 mai 2003, =E0 03:53 Europe/Paris,
>> sean.upton@uniontrib.com a =E9crit :
>>
>>>> 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
>>>
>>> _______________________________________________
>>> Zope-CMF maillist  -  Zope-CMF@zope.org
>>> http://mail.zope.org/mailman/listinfo/zope-cmf
>>>
>>> See http://collector.zope.org/CMF for bug reports and
>> feature requests
>>>
>>
>