[ic] dist/mvmall?

Mike Heins mikeh@minivend.com
Sat, 30 Sep 2000 10:36:20 -0400


Quoting Steve & Patti Getzinger (steveandpatti@wubs.org):
>   I have done a couple "malls" in the past and am wondering why the concept
>   of same shipping and orders. When I started I tried to pattern after real
>   life. In real life all the mall does is provide service for the store
>   owners. Each store maintains it's own cash register systems. As to "golf"
>   themes build it. Here is a basic outline of what I used and if it sounds
>   outrageous it works :) All I have done have been on 3.14 or below.
> 
>   The main mall catalog holds info about the "themes" and stores. Each
>   "theme" holds info about the stores in that "theme". Each store holds info
>   about itself. ProductFiles of the main mall holds the paths to the products
>   files of every store. This allows product searching from the main mall area
>   of all products in the mall. "Theme" ProductFiles holds the paths to all
>   the products files of all the stores in that "theme". No need for shipping
>   or tax or quantity or ... in main mall or theme areas as they do none of
>   these things.

The problem with using separate product files is that the mall is not scalable
to thousands of stores, or not even to a busy hundred-store mall. The overhead
gets to be too much.

This type of thing is very scalable, though:

interchange.cfg:

GlobalSub <<EOR
sub mall {
    if($CGI->{store_reset}) {
        delete $Session->{store_id};
    }
    unless($Session->{store_id}) {
        my $url = $Session->{last_url};
        $url =~ s:^/([-\w]+)::;
        $Session->{store_id} = $1;
        $CGI->{mv_nextpage} = 'dir';
    }
    my $id = $Session->{store_id};
    my $ref = $Db{store}->row_hash($id);
    if(! $ref) {
        $id = $Session->{store_id} = 'default';
        $ref = $Db{store}->row_hash($id);
    }

    if($ref->{price_level} =~ /([a-z])/) {
        $Config->{PriceField} .= "_$1";
    }
    @defs = split /\s+/, $::Variable->{LOOK_DEFS};
    for(qw/__LOOK_DEFS__/) {
        Log("$_ points to " . $ref->{lc $_});
        $Variable->{$_} = $ref->{lc $_} || $Variable->{"DEFAULT_$_"};
    }
}
EOR

catalog.cfg:

Variable LOOK_DEFS    BGCOLOR HEADER FOOTER ALINK ETC ETC
Autoload mall

AT that point, the admin interface is pretty easy. You just set
owner_field permissions for the products table in the access.asc files,
give insert permission, and the owner can maintain their own products
and possibly even their own setup in the store database via the UI.

This is scalable to many thousands of stores.

> 
>   Yes I can not buy something from store A and B and have it on the same
>   order form but I found to many variables involved to make that happen well
>   and that is not the way it is at the mall down the street :) I got as far
>   as since many of the stores were in the same zip I started defining a
>   central zone file (saved server space) As I got a new store (zone) I
>   downloaded the ups file and put it in the main mall area. Now when a new
>   store came on board in the same zone just delete the files from that stores
>   catalog and point to the correct file in the main mall area. Alternative
>   was just let each store owner handle shipping.
> 

That is what I was talking about. Can users combine products? Do they
have to execute a different checkout in sequence for each store? Do some
stores use CyberCash and some not? Who writes the custom shipping routines
and what modes do you support? How do you manage the PGP keys? This is
an exercise, believe me.

-- 
Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.8220 fax 7501 <heins@akopia.com>

Any man who is under 30, and is not liberal, has not heart; and any man
who is over 30, and is not a conservative, has not brains.
 -- Winston Churchill