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

sean.upton@uniontrib.com sean.upton@uniontrib.com
Tue, 27 May 2003 10:10:14 -0700

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:

Your best bet may be to start by writing all the code you need to access
your user/member data as ZSQL methods and TTW Python Scripts in a folder as
a means of prototyping your user access.   Once you have this working, I
would suggest turning it into a CMF tool written as a python product (your
tool is a class inheriting from Folder, and you re-implement all the scripts
you wrote originally as TTW Python Scripts as class methods - they would
still access the ZSQL methods in the folder, but you would likely need to
automate adding the ZSQL methods to the folder on its creation from method
templates on the filesystem - you can likely use code in the
SimpleUserFolder unit tests as an example of how to do this), writing a user
folder next that uses the previously mentioned tool to abstract all the ZSQL
methods and queries running behind the scenes, and third, tackling the
memberdata tool.

Again, this is a fair amount of work, but it is likely the right path to
having a membership source that is integrated with a custom database for
BOTH authentication and user data access (as opposed to more general purpose
membership sources: built-in, LDAP, etc).


-----Original Message-----
From: Eric CESTARI [mailto:eric@ohmforce.com]
Sent: Tuesday, May 27, 2003 12:01 AM
To: Zope-CMF List
Cc: archives@ohmforce.com
Subject: [Zope-CMF] Store development with CMF (new guy)

Hi all,

I've been a lurker here for some time, and now it's time to step up ... 
First thanks to you guys for making such a nice platform to develop on !

I plan to completely rewrite my company's website (currently PHP) in a 
CMFPlone solution.
The pros are completely obvious, yet I have a few questions so that I 
can do it the Right Way(tm).

We have a 30,000+ user Postgres database. I feel it is not a sensible 
solution to store this in the ZODB, and I'd rather keep it in Postgres 
and use exUserFolder and ZPopyDA.
Am I right, or can I get rid of this complexity ?

Those user would be members not allowed to add any content except in 
the forums, and fetch our products updates (based on the products they 
bought), demos and free stuff.

I also plan to use CMFCommerce as my store backbone. Our CC processor 
gave us a couple of Java classes to connect to their servers, I will 
certainly use JavaPythonExtension to connect to it. Are there any 
pitfalls on this path ? (I had so many problems with PHP/Java, we ended 
up having PHP including URL from a Tomcat server).

Anyway I'm glad to take on development on CMF, though the walk looks 
steep on the first miles :)


PS : Hey Marc, are there any plans to add CMF hooks in Plugzilla ? Nice 
to meet you here :)

Eric Cestari
Audio Plugins
Ohm Force

Zope-CMF maillist  -  Zope-CMF@zope.org

See http://collector.zope.org/CMF for bug reports and feature requests