[Zope-CMF] Re: Member tools refactoring (Was: Better MemberData search

Miles Waller miles at jamkit.com
Mon Nov 3 07:10:15 EST 2003


Hi,

>
> another possible angle on all of this is CMFMember, which replaces the
> default memberdata tool with one that provides Archetypes-based
> memberdata objects.  this already provides some (most?) of the
> functionality you're suggesting in the userdirectory tool, i believe.
>
> i'm pretty sure that Archetypes and CMFMember are still Plone-specific
> for now, but i thought i heard rumblings that Archetypes might be
> considered to be rolled directly into the CMF... if not it could
> probably be made to at least work w/ CMF-sans-Plone.
>

AFAICS, CMFMember covers two sets of requirements:

 - put members through a workflow
 - use archetypes to configure member objects which behave like normal zope
objects

The ability to workflow users is really useful, but I'd like to see the
above requirements separated a bit further if it was going to be rolled into
CMF: if your requirement is to access membership information stored anywhere
other than in zope (e.g. mySQL) I suspect you'd end up removing most of
CMFMember.  It would be useful to get the same benefits in a storage-neutral
way.  For example, one way of achieving this would be:

 - A registration tool that is a container for workflows that apply to user
accounts.  Users are not content, and it's important to keep that
distinction.
 - The member workflows would be modified slightly so that they would store
data directly in the member properties (so that they are independent of
wherever the member data is stored) rather than a 'review_state' attribute
created by the workflow.
 - The memberdata tool implemented as a folder of member objects set up
using archetypes would be one implementation of a memberdata tool that you
could use, but it would also be possible to use any memberdata tool (e.g.
LDAP or mySQL)
 - The current/standard memberdata tool, and the CMFMember Memberdata tool
would both use their own member catalog for searching, rather than
portal_catalog - members are not content and so they should be kept
separate.

Obviously this does not cover the case where you want to query two different
sets of users, but I think Lennart covered that pretty clearly in his last
email.

Miles




More information about the Zope-CMF mailing list