The simple catalog really isn't. It is a fairly full-featured demonstration of MiniVend capabilities, though not nearly all of its features are used there.
It uses the Variable
feature extensively to simplify hand page editing. Basically speaking, a Variable
is a define that allows you to substitute text for a simple
__VARIABLE__ string in your page.
For example, in the simple demo, this is a complete page with the standard layout:
__LOGOBAR__ __MENUBAR__ __LEFTSIDE__ This is your content. __RIGHTSIDE__ __MENUBOTTOM__ __COPYRIGHT__
The way this looks on the page, roughly, is:
+--------------------------------------------------------+ | __LOGOBAR__ | |--------------------------------------------------------+ | __MENUBAR__ | |--------------+-------------------------+---------------+ | | | | | __LEFTSIDE__ | This is your content | __RIGHTSIDE__ | | | | | | | | | +--------------+-------------------------+---------------+ | __MENUBOTTOM__ | |--------------------------------------------------------+ | __COPYRIGHT__ | +--------------------------------------------------------+
The __RIGHTSIDE__ is simply defined to be empty, closing table HTML in most cases, so it really is this in most pages:
+--------------------------------------------------------+ | __LOGOBAR__ | |--------------------------------------------------------+ | __MENUBAR__ | |--------------+-----------------------------------------+ | | | | __LEFTSIDE__ | This is your content | | | | | | | +--------------+-----------------------------------------+ | __MENUBOTTOM__ | |--------------------------------------------------------+ | __COPYRIGHT__ | +--------------------------------------------------------+
The variables are defined in catalog.cfg
, and come from files in the config directory. There are conditional
templates with some different color schemes.
Once you get used to using this method, it can be quite convenient. But you may certainly choose to use your own method, perhaps one based on an HTML editor. MiniVend can coexist with some editors; ones that have a <NOTOUCH> </NOTOUCH> or <NOEDIT> </NOEDIT> pair to define areas that should not be ``masterminded'' by the editor are best.
Bear in mind that this templating method and database layout of the simple catalog is a loose suggestion on how your catalog might be organized. Many users decide to do their own database structure for product display. What you can do is more limited by your imagination than anything.
Yet most users stick with the userdb and checkout strategies employed in the catalog. This is because they have been developed over a period of years and work. Still, these can be customized; you can make it operate like Amazon or another site if you wish.
As stated before, MiniVend catalogs are all about the database. The simple demo has several tables:
A table designed to implement a dynamic navigation
bar. It is read and parsed to display the areas Galleries
, Other Stuff
, and Links
as distributed. Simply by changing the contents of the area table you can change the left side navigation bar. The value of the field
selector is used to search the cat table to find which categories belong in each area.
The product structure of simple follows a single-level categorization. Categories are listed in the cat database table. The cat table is designed to allow you to display meta-information about each category when it is displayed. The fields are:
The category code. Must be unique.
The area this category should be displayed in.
The selector that is used to scan the products table for products in the category.
A label to display, so that you don't have to live with the code or selector.
Text to display in a banner or heading.
Placeholder in the demo; intended to allow selection of certain subcategories within the category.
The sort order if you don't want alphanumeric on name.
A URL to link to instead of the default search in the products database.
A list of countries; used to build select boxes and select shipping modes based on countries.
Two fields; code and quantity. Minivend's demo will decrement the quantity based on the sale. That is easy; your method of keeping inventory current is the hard part. It might make sense to add a field with the usual shipping time of the product; something like ``ships within 24 hours'', or ``back ordered; allow 2-4 weeks for delivery''.
A database that works in conjunction with the CommonAdjust
directive to allow quantity pricing, either for one product or for a group
of products (sometimes known as mix-and-match). The fields q2,q5,q10,etc.
are for the quantity levels; the price_group
field selects the mix-and-match category for the product.
The main product table. This is where you store your product information. You can add, delete, or ignore fields as you choose. Field by field:
The unique identifier for the product. Though theoretically it can contain
most any character, you should use only characters of the class
A-Z a-z 0-9 _ -
if you want to be easily compatible with
SQL databases and
URL encoding. Other characters can cause problems; a slash (
/
) can interfere with URLs and filenames; a colon (:
) can interfere with database representations (or file names on some
operating systems); and there are other possible compatibility situations
with other characters.
A short description for the product, used for displaying in the shopping cart, receipt, and order report. Keep it short.
This is somewhat catalog-specific since it applies to art. However, it would also apply to books, CDs, or other items.
This is somewhat catalog-specific since it applies to art. However, it
would also apply to CDs, or some other items. You can change it to anything
if you remember to change the field names in your catalog pages to match;
to do so look for all occurences of the string ``artist'' in the pages, special_pages
, and etc directories.
A long description of the product. If you use the Minivend internal database, the field size is unlimited; if you use another type of database then you will be dependent on the field type you select.
Catalog-specific to show the museum the art work is displayed at. You can use or delete this field as you wish.
The image filename for the product. Many people add a thumb
field to contain the name of a small image for search list display.
The quantity-one price of the product.
The category used for selection in lists. It is possible to place a product in more than one category, though you will have some display and banner heading decisions to make based upon this. You can use embedded Perl or other methods to deal with this.
If set to 1
, the product is not taxable and its price will not be used in a salestax
calculation.
A numeric value of the weight, used for determining shipping costs. Normally in pounds, but can be anything your shipping routines will handle.
A comma-separated list of options as used in Accessories
. See the
flypage.html
and ord/basket.html
pages for examples of how it is used.
A comma-separated list of options as used in Accessories
. See the
flypage.html
and ord/basket.html
pages for examples of how it is used.
Used in the demo to display ``upsells'', meaning opportunities to purchase an additional item when you purchase this one. Contains a list of SKUs to be offered.
As used in this demo, the only value that means anything is front
. If that is contained in the field, this product will possibly be featured
on the front page via random selection. See the index.html
page for how it integrates with [loop search=something random=3]
.
Every line item that is actually ordered is detailed in this table. See the
page query/check_orders.html
for how it might be used; see etc/report
for how it is added to.
Each individual customer order is detailed in this table. See the page query/check_orders.html
for how it might be used; see etc/report
for how it is added to.
The user database used for maintaining customer address information,
account information, preferences, and more. See UserDB
.