[Zope-CMF] Understanding Tool Construction

[Edward Muller]

A lot of what I am doing will be e-commerce based 'stuff' that needs to
fit into an existing plone site.

Based on the what I saw and how I thought it was being used I figured
certain portions of what I needed to write would be be done as a tool.
For instance I think it makes sense to have a credit card gateway a
shopping cart tool. The actual items in the cart would be content types
and the way the cart would be displayed would be a skin. But the methods
for manipulating the cart, saving it, restoring it at later visits,
associating it with Members, etc would be the tool.

Which brings up another question.... :-)

I was thinking of making customers members of the site, but the default
install of plone at least (and possibly cmf) allows members to create
and publish content. While my customers would want some members to be
able to publish content on the whole site and some others to be able to
add content to their private spaces, they won't want customers to be
able to add much beyond product reviews and possibly trouble tickets.

Any suggestions for hacking that up, or is it already in there...I just
need to create the roles and adjust/assign permissions/create new ones.

On Mon, 2003-08-04 at 06:09, Tres Seaver wrote:
> On Mon, 2003-08-04 at 06:41, Chris Withers wrote:
> 
> > > Okay, then what is a tool for then? 
> > 
> > Providing a generic service that is required for all types of CMF site.
> > 
> > As a general rule of thumb, most of the good candidates for tools have already 
> > been implemented ;-)
> 
> Chris, your imagination is too limited here:  the existing tools cover
> only a small slice of possible services / utilities.  On my current
> project, we have added several *dozen* tools, of different flavors.  The
> key difference between skin methods and tools is that tools often do
> "heavy lifting", and hence need to be unit tested, as well as running as
> "trusted code".
> 
> To address Edward's original question:
> 
> Many tools can be prototyped as a folder full of external methods: the
> skin templates / methods which call them won't know or care the
> difference.  If the tool needs persistent state (e.g., a relationship
> service :), then it gets built that way from scratch.  Once the tool
> gels, write an interface for it, and ensure that the clients depend only
> on that interface, to allow easy replacement later.
> 
> Tres.
-- 
Edward Muller

Interlix (http://www.interlix.com)
Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572

Web Hosting - PC Service & Support - Custom Programming - Network Service & Support
Specializing in Open Source Solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.zope.org/pipermail/zope-cmf/attachments/20030804/3381b5e5/attachment.bin