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

Shane Hathaway shane@zope.com
Tue, 27 May 2003 13:30:52 -0400

sean.upton@uniontrib.com wrote:
> Your user database: you would like to maintain its structure as it is, in
> postgres, no?
> If you want to do this, you likely need to write some product code and
> replace some CMF tools.  This is not the easiest path, so you should
> determine if you really need this level of integration...  with the number
> of users you indicate, and the investment in an existing system, I would
> suggest at least considering this, even though it is a lot of work.
> If so, likely what you will need is a custom-built user-folder and a
> custom-built memberdata tool: replacements for the stock tools that are
> interface compatible.   The stock portal_membership tool will work with and
> use these two custom tools.  IMHO, these are hard to develop from scratch (I
> just went through this to develop a membership system with a custom
> MySQL-based backend); it works, but it took a fair amount of patience to put
> together.  I used SimpleUserFolder as a base class for my user folder, and
> wrote a memberdata tool that did not rely upon sub-classing the stock tools
> (just made it interface compatible).  For purpose of reference a diagram for
> what I did for my custom memberdata setup:

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.)