
Zope Product "EMarket".

README.txt $Revision: 1.18 $

EMarket has evolved a lot since it was first introduced
shorly after Zope-1.0. Zope has evolved a lot too! 
A lot of change has occured since the last release. This
release uses ZPatterns so that the developer can
integrate the code in a very flexible way. In order
to get this release out the door in the limited time I
have available, I cut out most of the auction/trading
code. That can be restored once we get the basic
functionality debugged and working smoothly. 

There is also a lot of code here, mostly due to R David Murray
<rdmurray@bitdance.com>. He has added a ZCatalog index and other great
things. As usual, the source is currently the best documentation. I
have little time to work on this at the moment, but I hope that will
change later this summer.

Basically an EMarket is a folderish object that (currently) consists
of a set of methods and five folderish 'Specialists'. Each specialist
is responsible for managing one particular type of object. They have
methods, and racks: methods to interface to the rest of the application,
and racks to handle the storage and retrieval of the objects
they manage:

marketItems: manage the market items in the EMarket

shoppers: manage the shopper objects

basketManager: manage the 'shopping baskets'

basketItemManager: manage the items in the shopping baskets.

transactions: manage the completed transactions

The idea here is to provide a framework for a 'shopping area' that is
at once flexible, simple, and reasonably robust. The display of the
market area is determined by editable templates that are contained in
the marketItems folder. The display of the shopping 'Baskets' is
managed by templates in the shoppers folder. This way each EMarket can
be customized easily. Also, the developer picks the classes they
want to use for shoppers, marketItems, etc... so they can also be used
to customize the look and feel of the market.

After you install an EMarket, the first thing to do is set up storage
classes for each of the specialists. Each specialist needs a ZClass
(subclasses from ZPatterns:DataSkin) associated with it. The
requirements of these classes are as follows:

1) marketItemZClass:

attributes:

name         (string)
description  (string)
available    (boolean)

methods:

index_html

You will also want/need a management interface for the marketItems. Since it's
your class.. you'll need to cook it up. Once I get a good example working
I'll supply an example marketItem ZClass.... the project I'm working on
get's it's marketItems from a different source (using the magic of ZPatterns)
so the marketItem class is really just a 'stand' in.

2) shopperZClass

attributes:

email     (string)
passwd    (string)

methods:

none yet... 

3) basket

attributes:

basketItemIds   (tokens)

methods:

none yet... 
(There is really no need for you to do much with this other than
supply a 'stand-in' ZClass to contain the data. If you want a
management interface for baskets.... go for it.)

4) basketItem

attributes:

itemID   (string)
quantity (int)

methods:

none yet... 

(There is really no need for you to do much with this other than
supply a 'stand-in' ZClass to contain the data. If you want a
management interface for baskets.... go for it.)

4) transaction

this class is not currently used... I'm still working on a default
finalization interface. It seems that this is generally differnt
for each client.. so I'm having trouble coming up with a 'default'.

Good Luck!
-steve

