[Zope-CMF] Store development with CMF (new guy)
Tue, 27 May 2003 23:56:19 +0300
hi Shane, great info!
...Is there a place where the logic that you explained here (and
other similar stuff) is documented so that one can avoid making bad
design decisions (such as the kind you are advising against)?
At 13:30 -0400 27.5.2003, Shane Hathaway wrote:
>Actually, just *delete* the portal_memberdata tool. Part of its
>contract is that it can be removed safely; that's why all of its
>methods are private. The portal_memberdata tool is purely a user
>decorator. If the user objects already have the attributes required
>by the application, you don't need to decorate the user objects to
>make them members. The only dependency on portal_memberdata is from
>portal_membership, which defaults to not decorating users if there
>is no portal_memberdata. No other code or skins should depend on
>portal_memberdata! (If it does, it has a bug.)
At 15:42 -0400 27.5.2003, Shane Hathaway wrote:
>>Unfortunately, a lot of apps (I think, including CMFDefault, Plone) depend
>>on accessing decorated "member object" instead of non-decorated users, or at
>>least accessing certain properties (either via PropertyManager methods or to
>>my displeasure via direct attribute access). I've just operated under the
>>assumption that there are 'official' interfaces that members and the
>>memberdata tool need to support, and de-facto ones: for example, it isn't
>>documented anywhere that the memberdata tool needs to implement the
>>PropertyManager interface, but many applications and skin scripts
>>applications assume it does, i.e. in ZPTs to iterate through propertyIds()
>>for a user-properties form. Given this, I decided in my tools to target the
>>assumptions that applications make about the interface of these components
>>instead of just their official interfaces.
>I'm sorry to hear that so many applications are broken. CMF product
>authors: do not rely on portal_memberdata. Assume it does not exist.