![]() |
||
![]() |
1.0.4 Documentation | ![]() |
![]() |
![]() |
4. Customer Interaction4.1 About Interfaces in General4.1.1 Manual, Automatic, and Realtime Content4.1.2 User Login and Account CreationScripts covered by this document:
Templates covered by this document:
4.1.2.1 welcome.cgiThe welcome.cgi script is used to handle customer logins to your website. These can be either new or returning customers. welcome.cgi lives under the directory path "document_root"/cgi-bin/om/welcome.cgi. You should familiarize yourself with this description of welcome.cgi and get these examples working on your site before attempting to set up a shopping cart using cart.cgi, since it will want to call welcome.cgi under certain circumstances. There are three HTML template files that welcome.cgi uses; these must be present in sites/pages in order to use this script. It is also necessary to have two "cell" files located in bits/cells. The three page templates used by welcome.cgi are meant to handle three possible conditions on execution of welcome.cgi. These are:
The two most likely situations in which welcome.cgi will be called are:
The first HTML template you will need is "page_welcome_login.txt". welcome.cgi looks for this (as well as the other two templates) by name, so you must use this name for the file unless you want to edit welcome.cgi itself to look for differently-named files. Here's an example of a minimal version of this template: <HTML> <!-- page_welcome_login.txt --> <HEAD> <TITLE>Please Sign In to __storename__ </TITLE> </HEAD> <BODY BGCOLOR="#FFDD66" LINK="#300" VLINK="#333" MARGINHEIGHT="0" MARGINWIDTH="0" LEFTMARGIN="0" TOPMARGIN="0"> <FORM METHOD="POST" ACTION="/cgi-bin/om/__scriptname__"> <INPUT TYPE=HIDDEN NAME="pg_targ" VALUE="__pg_targ__"> <INPUT TYPE=HIDDEN NAME="sid" VALUE="__sid__"><BR> <TABLE> <TR COLSPAN=4 BGCOLOR="#AAAAAA" WIDTH=> <TD>My site Login</TD> </TR> __cell_welcome_new_cust__ __cell_welcome_return_cust__ </TABLE> </FORM> </BODY> </HTML> Let's do a little parsing of this template! The first part that is not HTML is in the title. It's not too unusual, except for the "__storename__" text. When this part of the template is parsed by a call to permutebit(), located in filetools.pm, it is replaced with the actual store name, as assigned in store.pm. Notice that in the ACTION reference for the FORM tag, there is again a similar string. This gets replaced with the name of the script that generates the page -- welcome.cgi in this case. In the first "hidden" value, there is a parameter named "pg_targ" and an associated value of "__pg_targ__". By now, you've probably caught on to the fact that whenever AllCommerce sees a reference to "__a_value__" in a template, it replaces the reference with an actual value during page generation. In this case, "__pg_targ_" can get one of several possible values, depending on how welcome.cgi was called. As an example: a customer places an item in their shopping cart which executes the cart.cgi script. On the shopping cart contents display page will be a link (among others) to checkout. Within the HTML for this page will also be the hidden value named "pg_targ", with a value of checkout.cgi. When welcome.cgi is called and examines the values passed to it, it uses the value for "pg_targ" as a hyperlink reference to display on the page it generates upon successful customer login. This might, for example, be a button labeled "continue". Thus, the customer is directed back to their original destination of checkout.cgi (in this example), after having been diverted to welcome.cgi in order to login. So, you would put into your login confirmation page something like: <A HREF="__pg_targ__">Continue with Checkout</A> "__pg_targ__" would be replaced with checkout.cgi when this page is generated (in this example). We'll go into more detail of how the login confirmation pages look later in this section. If there is no value for "__pg_targ__", then welcome.cgi will use the page that the customer came from, if it is part of the site. A link to login from the home page is a good example. If welcome.cgi was not called from within the site, the value for "pg_targ" will be set to "home.shtml". The default is to set "pg_targ" to checkout.cgi if none of the above can be determined. The last of the hidden values is that for "sid". This is the unique session id that is set for each visitor to the site (as a tracking mechanism). Next, we see a table with references to two "cell" files. Again, these values are replaced during page generation, but these are references to even smaller HTML templates which may themselves have references for further replacement within them. These files are named "cell_welcome_new_cust.txt" and "cell_welcome_return_cust.txt", respectively. They need to be in sitename/bits/cells. These "cells" contain the text and data entry fields for a returning customer or a new customer. Here's another minimal example of how "cell_welcome_new_cust.txt" might look: <!------- New customer email address ---------------------> <TR> <TD VALIGN=TOP> <INPUT TYPE=TEXT NAME="new.email_inp" VALUE="__new.email_inp__" SIZE=20> </TD> <TD VALIGN=TOP> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-1 COLOR="#999933"><B>Your email address</B> </FONT><BR> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-2 COLOR="#999933">(user@domain.com) </FONT><BR> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-2 COLOR="#FF0000">__new.email_err__ </FONT> </TD> </TR> <!------- New customer password --------------------------> <TR> <TD VALIGN=TOP><INPUT TYPE=PASSWORD NAME="new.passwd1_inp" SIZE=20> </TD> <TD VALIGN=TOP> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-1 COLOR="#999933"><B>Enter a password</B> </FONT><BR> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-2 COLOR="#999933">(5 to 20 characters) </FONT><BR> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-2 COLOR="#FF0000">__new.passwd_err__ </FONT> </TD> </TR> <!-------New customer password verify -------------------> <TR> <TD VALIGN=TOP> <INPUT TYPE=PASSWORD NAME="new.passwd2_inp" SIZE=20> </TD> <TD VALIGN=TOP> <FONT FACE="verdana,geneva,arial,helvetica"<BR> <B>Enter your password again</B> </FONT><BR> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-2 COLOR="#FF0000">__new.passwd_err__ </FONT> </TD> </TR> <!------- New customer hint -----------------------------> <TR> <TD VALIGN=TOP><INPUT TYPE=TEXT NAME="new.hint_inp" VALUE="__new.hint_inp__" SIZE=20> </TD> <TD VALIGN=TOP> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-1 COLOR="#999933"><B>Enter a hint</B> (Optional) </FONT><BR> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-2 COLOR="#999933"> This is a clue that will help you to remember your password. For example, "What is the name of your BIG toe?" </FONT><BR> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-2 COLOR="#FF0000">__new.hint_err__ </FONT> </TD> </TR> <TR> <TD>&NBSP;</TD> <TD ALIGN=RIGHT> <INPUT TYPE=SUBMIT VALUE="Submit or else!"> </TD> </TR> Well, not quite so minimal. There's a lot of stuff about font types, but the important information is in the data entry areas. The things to note (and be sure to use in your own templates) are the names used for the email and password entry fields. "new.email_inp" and "new.passwd_inp" tell welcome.cgi (when it examines its name/value pairs) that these are entries for a new account, rather than data coming from the next cell template (which is for an existing account and will have the prefix "old", as in "old.email_inp" etc...). The areas with entries like "__new.hint_err__" are for replacement with error messages, should someone click submit having left some field empty as an example. In such a case, the page is redisplayed with values the customer entered, along with error messages. If there are no error messages, as in the first time welcome.cgi displays this page, all error message references are simply removed before the HTML is sent to the web server. The next "cell" is "cell_welcome_return_cust.txt", which contains text entry fields for a returning customer. Here, again, is a minimal example of this cell: <TR> <TD COLSPAN=2> <FONT FACE="verdana,geneva,arial,helvetica" COLOR="#999933"> <B>If you already have a __storename__ account:</B> </FONT><BR> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-1 COLOR="#999933"> Just type in your email address and password to checkout. </FONT><P> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-1 COLOR="#FF0000">__old.login_err__ </FONT > </TD> </TR> <TR> <TD> <IMG SRC="/images/general/dot.gif" WIDTH="100" HEIGHT="5"> </TD> <TD> <IMG SRC="/images/general/dot.gif" WIDTH="200" HEIGHT="1"> </TD> </TR> <!------- Returning customer email address---------------> <TR> <TD VALIGN=TOP> <INPUT TYPE=TEXT NAME="old.email_inp" VALUE="__old.email_inp__" SIZE=20> <INPUT TYPE=HIDDEN NAME="old.email_pre" VALUE="__old.email_inp__"> </TD> <TD VALIGN=TOP> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-1 COLOR="#999933"><B>Your email address</B> </FONT><BR> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-2 COLOR="#999933">(user@domain.com) </FONT><BR> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-2 COLOR="#FF0000">__old.email_err__ </FONT > </TD> </TR> <!------- Returning customer password ------------------> <TR> <TD VALIGN=TOP> <INPUT TYPE=PASSWORD NAME="old.passwd_inp" SIZE=20> </TD> <TD VALIGN=TOP> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-1 COLOR="#999933"> <B>Your __storename__ password</B> <P> Forgot your password? <A HREF="/cgi-bin/hint.cgi?pg_targ=__pg_targ__" >Retrieve your hint.</A> </FONT><BR> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-2 COLOR="#FF0000" >__old.passwd_err__ </TD> </TR> <!------- Returning customer submit button -------------> <TR> <TD> <FONT FACE="verdana,geneva,arial,helvetica" SIZE=-1> <A HREF="/cgi-bin/checkout.cgi" >Forgot your password?</A> </FONT> </TD> <TD ALIGN=LEFT><INPUT TYPE=SUBMIT VALUE="Submit"> </TD> </TR> There's not much to say about this cell that's terribly different from the previous cell, except that the prefixes for the email and password entries are "old", rather than new as in "cell_welcome_new_cust.txt". This is used in welcome.cgi to determine whether to look for an existing record or create a new one. The other item to note is the call to hint.cgi. 4.1.2.2 Retrieving a Password Hint with hint.cgiWithin the "Returning customer password" section in the previous template is a call to hint.cgi. If someone can't remember their password and wishes to retrieve their hint, they can click on this link to have hint.cgi retrieve it for them. If they do, then hint.cgi also needs -- you guessed it! -- a template for data entry and output, called "page_hint_lookup.txt". Here's an example: <HTML> <HEAD> <TITLE>__storename__ | Your password hint</TITLE> </HEAD> <!-- page_hint_lookup.txt --> <BODY LINK="#300" VLINK="#333" MARGINHEIGHT="0" MARGINWIDTH="0" LEFTMARGIN="0" TOPMARGIN="0"> <FORM METHOD="POST" ACTION="/cgi-bin/hint.cgi"> <INPUT TYPE=HIDDEN NAME="pg_targ" VALUE="__pg_targ__"> <INPUT TYPE=HIDDEN NAME="sid" VALUE="__sid__"> <BR> <TABLE CELLSPACING="0" CELLPADDING="0" BORDER=0 ALIGN="CENTER"> <TR> <TD><B>Forgot My Password</B></TD> <TD>I can't remember my password. Please tell me what my hint is.</TD> </TR> <TR> <TD> <TABLE BORDER=0 CELLSPACING="0" CELLPADDING="0"> <TR> <TD> __hint_err__<B>Your email address:</B> (user@domain.com)<BR> </TD> </TR> <TR> <TD> __email_err__<BR> <INPUT TYPE=TEXT NAME="email_inp" VALUE="__email_inp__" SIZE=20> </TD> <TD ALIGN=MIDDLE> <INPUT TYPE=SUBMIT VALUE="submit"> </TD> </TR> <TR> <TD> <A HREF="/cgi-bin/welcome.cgi?pg_targ=__pg_targ__"> I'm now ready to login. </A> </TD> </TR> </TABLE> </TR> </TABLE> </FORM> </BODY> </HTML> This allows the customer to enter their email address and have hint.cgi retrieve the hint they entered when they first created their account. It also keeps passing along whatever "pg_targ" was when hint.cgi was called from welcome.cgi's first page. 4.1.2.3 Back to welcome.cgiGetting back to welcome.cgi, there are two more HTML templates you'll need for it. The next one is "page_welcome_confirm.txt". Here's an example: <HTML> <HEAD> <TITLE>__storename__ | Account created</TITLE> </HEAD> <!-- page_welcome_confirm.txt--> <BODY> <TABLE CELLSPACING="0" CELLPADDING="0" BORDER=0 ALIGN="CENTER"> <TR> <TD> <B>Account created</B> <B>Congratulations on setting up your new __storename__ account!</B><P> You have created an account with __storename__ using the following information: </TD> </TR> <TR> <TD>Account name:<B>__email__</B> </TD> </TR> <TR> <TD> Password: <B>__passwd__</B> </TD> <TD> Please write this information down or print out this page and keep it in an empty ice cream container in your freezer. </TD> </TR> <TR> <TD> <A HREF="/html/__pg_targ__">Continue</A> </TD> </TR> </TABLE> </BODY> </HTML> By now, you probably understand the special references in this template and their uses. This page is what welcome.cgi displays upon successful creation of a new account. It also contains a continuation link that points to checkout.cgi, the site's home page, or whatever page the customer came from for login. The final template you will need is for welcoming back a returning customer. It also has a place for welcome.cgi to insert a continuation link. Behold "page_welcome_onwards.txt": <HTML> <HEAD> <TITLE>__storename__ Login Success</TITLE> </HEAD> <!-- page_welcome_onwards.txt --> <BODY MARGINHEIGHT="0" MARGINWIDTH="0" LEFTMARGIN="0" TOPMARGIN="0"><BR> <TABLE CELLSPACING="0" CALLPADDING="0" BORDER=0 ALIGN="center"> <TR> <TD> <B>You are now logged in to __storename__ Remember to close your browser when you leave your machine unattended!</B> <P>Account name:<B>__email__</B> <P>Password: <B>__passwd__</B> <P>Please continue </TD> </TR> <TR> <TD> <A HREF="__pg_targ__">Continue</A> </TD> </TR> </TABLE> </BODY> </HTML> This should get you started in setting up the initial stages of AllCommerce to run your website. Now, we're ready to take a look at how to use cart.cgi. 4.1.3 The Shopping Cart4.1.3.1 Adding Shopping Carts to Your WebsiteThis document describes how to implement the cart.cgi script. It will provide your website with a functional "shopping cart" which allows customers to select items for purchase from your site. This document also describes the different types of carts that are created, how they are created, and what they are used for. cart.cgi will need to be able to make calls to welcome.cgi. It is therefore assumed that you have read the document welcome.cgi_overview.txt. That document describes the necessary templates for welcome.cgi, as well as explaining when and how the script would be executed. You will also find it helpful to read creating_templates.txt for an in-depth explanation of how templates are used in AllCommerce. 4.1.3.2 Quick StartIf you just want to get cart.cgi up and running without reading any of the script's gory details, you should read the section on templates for cart.cgi. This should be sufficient to allow you to test a shopping cart on your site. Remember, you need to implement welcome.cgi as well, or you may get some strange results. 4.1.3.3 Templates and Form Elements for cart.cgiAs in welcome.cgi, cart.cgi is also dependent on having a template available for dynamic output to display a shopping cart's contents. This section will also describe the form elements you will need to have on product pages, or any page for which you wish to incorporate cart functionality. The one template required by cart.cgi is called: page_cart_cart.txt It must have this name unless you wish to change the code within the script, and it must be present in os_allcommerce{version}/bits/{lang}/html/pages if you are not using the sample store. This template's purpose is to display a customer's current shopping cart contents, and provide a link to checkout.cgi, or back to shopping. Here is a simple example for page_cart_cart.txt: <HTML> <HEAD> <TITLE>__storename__ | My shopping cart</TITLE> </HEAD> <!-- page_cart_cart.txt PM --> <BODY LINK="#300" VLINK="#333" MARGINHEIGHT="0" MARGINWIDTH="0" LEFTMARGIN="0" TOPMARGIN="0"> <FORM METHOD=POST ACTION="/cgi-bin/om/cart.cgi"> <INPUT TYPE=HIDDEN NAME="pg_targ" VALUE="__pg_targ__"> <INPUT TYPE=HIDDEN NAME="sid" VALUE="__sid__"> <INPUT TYPE=HIDDEN NAME="vcode" VALUE="__vcode__"> <TABLE BORDER=0 WIDTH= CELLSPACING=0 CELLPADDING=3> <TR> <TD COLSPAN=3> <FONT FACE="verdana,geneva,arial,helvetica" COLOR="#999933"> <B>My Cart</B> </FONT><BR> </TD> </TR> __newrow_cell_cart_header__ __newrow_cell_cart_list__ __newrow_cell_cart_buttons__ <TR> <TD COLSPAN=3> <FONT FACE="arial,helvetica,san-serif" SIZE=-1 COLOR="#999933"> To change a quantity, enter the <b>new quantity</B> and press the update button.<BR> To remove an item, select the checkbox next to <B>remove</B> and press the update button. </FONT> </TD> </TR> </TABLE> <TABLE BORDER=0 WIDTH= CELLSPACING=0 CELLPADDING=3> __cell_cart_header__ __cell_cart_list__ __cell_cart_buttons__ </TABLE> </FORM> </BODY> </HTML> This template also requires several cell files that are dynamically inserted into the generated page; they show individual products and their relevant information, such as price and quantity. These cells are replicated for each item that is currently in a customer's cart. Before discussing the cell files, let's look at the template itself. The only elements of absolute necessity within this template, other that the cell file references, are the values for the form tag. The first value, "pg_targ", is replaced by cart.cgi with a hyperlink to the previous page from which cart.cgi was called, if there is no value for it when cart.cgi is executed. It is left as is, if there is already a value. This could happen if cart.cgi was called from page_cart_cart.txt because a customer wanted to change the quantity of a certain item in their cart. In this case, cart.cgi says "Oh, I was called by a page I generated, so I don't need to figure out a value for pg_targ". You can actually hear it say this if you turn up your speakers real loud. For any other condition, "pg_targ" is replaced with a link to "home.shtml". The value "sid" is given a customer's session id. "vcode" is replaced with the single-character code that identifies a variant of a particular product. The concatenation of "vcode" and a product's sku make up the value for a "vcode", which is an element used in one of the cells that will be described in the next section. The submit button for this is in the cell_cart_buttons.txt cell file. 4.1.3.4 Cellscell_cart_header.txt This cell file simply supplies the default headings for the columns displayed on page_cart_cart.txt. Example: <!----- Titles of columns ------------------------------------> <TR> <TD><B>Product</B></TD> <TD><B>Price</B></TD> <TD><B>Qty.</B></TD> <TD><B>Remove</B</TD> </TR> Not too complicated, is it? The next cell: cell_cart_list.txt is used for displaying a shopping cart's contents. <TR> <TD> <A HREF="/html/__vsku__.shtml">__TITLE__</A><BR> __quant_err__ Sku number: __vsku__ </TD> <TD>$__unitpr__</TD> <TD ALIGN=MIDDLE> <INPUT TYPE=TEXT NAME="row.__rowid__.quant_inp" SIZE=3 VALUE="__quant__"> <INPUT TYPE=HIDDEN NAME="row.__rowid__.quant_pre" SIZE=3 VALUE="__quant__"> <INPUT TYPE=HIDDEN NAME="row.__rowid__.sku" SIZE=3 VALUE="__sku__"> <INPUT TYPE=HIDDEN NAME="row.__rowid__.vcode" SIZE=3 VALUE="__vcode__"> <INPUT TYPE=HIDDEN NAME="row.__rowid__.vsku" SIZE=3 VALUE="__vsku__"> </TD> <!----- Shopping List Checkbox ---------------------------> <TD ALIGN=MIDDLE> <INPUT TYPE=CHECKBOX NAME="row.__rowid__.kill" VALUE="on"> </TD> </TR> The hyperlink in the first table data is for a link back to the page for this product. __vsku__ is replaced by cart.cgi with the product's sku, which would also be the name of the product page with the .shtml suffix. __unitpr__ gets replaced with the product's actual price. The next section includes a textbox which contains the quantity (__quant__) of this product currently in the shopping cart. The following hidden value is for the previous quantity; if the two quantities are not the same, cart.cgi knows a customer wanted to change the quantity of this item. The __rowid__ tag requires a somewhat lengthy explanation, so if you're just interested in quick starting your cart for now, you might want to skim over this part. When a customer places their first item into a "shopping cart", cart.cgi creates a "tcart" (temporary cart) for this user. These tcarts exist in the tcart table. They are initially created in the levents table, but that's a story for later; please see "How Shopping Carts are Created". __sku__ is there to pass the product's sku back to cart.cgi so it knows what product this cell refers to. __vcode__ contains the variant code for this product (if it has one), and __vsku__ would contain the product's sku, with the vcode appended to it. All of these values are replaced by cart.cgi during execution; you just need to provide the references for them, as in this example. The next cell file, cell_cart_buttons.txt, is also quite simple: <!---------- Submit Buttons ----------------------------> <TR> <TD COLSPAN=3 ALIGN=CENTER> <A HREF="__pg_targ__">Continue</A> <INPUT TYPE=SUBMIT VALUE="Update"> <A HREF="__nextcheckoutpg__">Check Out</A> </TD> </TR> It's purpose is to allow a customer to call cart.cgi from this page if they are changing the quantity of a product in their cart, thus the submit button. Also, cart.cgi will convert __pg_targ__ is generally given the value (as a hyperlink) of the product page the customer was previously at. The last HREF, __nextcheckoutpg__, is a link to the next step in the checkout sequence. This will either be a hyperlink to checkout.cgi, or to welcome.cgi if the customer has not yet logged into the site. One last bit that needs explaining is why the first set of cell references begin with "__newrow__". cart.cgi replaces these cells with data for a product just added to the cart. As more items are added, previously existing ones are put into the second cell area on page_cart_cart.txt. There is only one new product for any particular instantiation of page_cart_cart.txt, but the second cell section is replicated for every other previously existing product in the shopper's cart. 4.1.3.5 Product PagesOn any page that displays a product and on which you wish to have some type of button allowing a customer to purchase this item, you will need a reference to cart.cgi plus some data to pass to it. Somewhere on your product pages, you will need this HTML: <FORM METHOD=POST ACTION="/cgi-bin/om/cart.cgi"> <INPUT TYPE=HIDDEN NAME="sid" VALUE="__sid__"> <INPUT TYPE=HIDDEN NAME="vsku" VALUE="__vsku__"> <INPUT TYPE=HIDDEN NAME="add" VALUE="1"> </FORM> Once these templates are created, in the proper directories with the proper names, and you put the necessary references to cart.cgi on your product pages, you should have functioning shopping carts on your site. 4.1.3.6 How Shopping Carts are CreatedWhen a customer is online putting items into their shopping cart, the cart that AllCommerce keeps track of for that person is known as a tcart (t for temporary). The levents table is where this cart begins life. This table is used to generate unique numbers for various purposes within AllCommerce and a reference for a tcart is one of them. Within the levents table is a field (dtable) which lists which table this event was created for, the tcart table is one example. The series field is appended after the event id with a "-" to form an id for the cart, "1-a" for example, which is entered as the value in the tcart table for the cartid field. After a cart id is generated, a LineId is generated for the lineid field within the tcart table. cart.cgi puts these values into the tcart table as one record, along with data about the product itself. Data such as the product's sku, its unit price, and quantity go in the tcart. This data is accessed during generation (or should we say, permutation) of page_cart_cart.txt. This data is actually used to replace the corresponding reference tags within cell_cart_list.txt. The __rowid__v tags within that cell template get the LineId from the tcart table, and cart.cgi permutes a new cell_cart_list.txt for each tcart whose sid field contains a value that matches the customer's sid. All cart creation is done within the function cartaddcheck(), located in lib/state.pm. The first time a customer actually clicks on a purchase button from a page displaying a product for sale, cart.cgi is executed and it checks to see whether or not this person already has a tcart for this product. If they do, and they are incrementing or decrementing the quantity for this product, the quant(ity) field is updated accordingly after a couple of checks are made to assure that there is sufficient stock, and that the new quantity won't exceed any limits set in store.pm (store_limit_all and/or store-limit-jit). If, on the other hand, there is no tcart for this product for this person, then cart.cgi first creates one, followed by a line-id. Now cart.cgi checks availability of the stock. This logic is actually performed in the subroutine "cartaddcheck()" in state.pm. The first check is made to the "inventory" table. The lstock, wh, and status fields are extracted for the record whose sku field matches the products sku and the "vcode" field matches the $var variable (which would be the product's variant code if it had one; otherwise, it's undefined). lstock holds the current stock quantity for the warehouse (wh) being checked. Currently, there is only logic to check for a wh value of 1. The code has been designed, however, to allow future upgrading to for multiple warehouses. The next thing that gets checked is the "behavior" field from the "things" table. While there are five possible values for "behavior", there are only two actual behavioral decisions that need to be made. These are done with respect to the values set in store.pm for "store_limit_jit" and "store-limit_all". If the behavior value for the product from the things table is "jt", then this is a "just in time" stock item and the quantity for this product within a shoppers cart may not exceed the value of "store_limit-jit". All other values for behavior cause cartaddcheck to compare a shopper's quantity of this item with that of "store_limit_all" and the value for lstock from the inventory table. If the shopper is not exceeding the store limit and lstock exceeds the currently requested quantity, then the item(s) is/are placed in their tcart. Otherwise, an error message advising them of this limit or lack of stock is generated and displayed on page_cart_cart.txt when it is permuted and sent to the shopper's browser. When the customer decides to checkout, a call is made, via a link on page_cart_cart.txt, to checkout.cgi. Then checkout.cgi converts all of a customers tcarts into a "pcart" (p for permanent) which can be referenced from the Order Manager to query for orders made online. 4.1.4 Checkout4.2 About Specific Interfaces4.2.1 HTML Browser-based Interfaces4.2.2 WAP4.2.3 Palm4.2.4 XML Order Export4.2.4.1 Purposeos_allcommerce/tools/xml_order_export.pl can be used to export the order information from the site database to a text file which is in XML format. XML Order Export takes as parameters a list of Order IDS (the objid key from the order table), separated by spaces. For each order ID input, the order information will be exported. These XML files can then be used to import data into external data sources, such as warehousing systems. For example, perl xml_order_export.pl 31-AA 44-AA This will export the order with the objid 31-AA and the order with the objid 44-AA, and all associated data from relational tables. 4.2.4.2 DataThe following tables are queried to gather the information regarding the order. 4.2.4.3 OrderTo find the information about the order, the user, addresses, price, and shipping weight of the order. Note that since this is a relational database, the values for the addresses, the user are just a key into another table. The actual data must then be retrieved from the other tables. Also, the ocart table must be queried to determine what all of the items are that are purchased. The following are the other tables that are queried to retrieve the information. 4.2.4.4 AddressesTo find the details about the shipping address and the billing address for this order. 4.2.4.5 ContactsTo give the user name of the individual who purchased this order. 4.2.4.6 ocartTo describe each item in the order cart that was purchased with this order. It is a list of all of the items purchased. 4.2.4.7 ThingsTo find the title of each item in the ocart. 4.2.4.8 Exported FileThe exported file is stored in the following directory: os_allcommerce/transit/export/order It will be named OBJID.xml, where OBJID is the order objid that was passed into the program at the command line. 4.2.4.9 Exported File Format
Templates can be generated to layout the format
of the exported files, but if none are created,
then a dump of the data in XML format is outputted.
All of the data is exported from the above tables,
with the You can create templates in the following directories: os_allcommerce/bits/eng/xml_pages They MUST have the following names: xml_page_order_format.txt This template outlines the format of the final .xml file. This file can have hard coded information, along with the following tags which will be replaced with the data gathered and represented from the other tables: __ORDER__ replaced with data from the order table in the default format if no template is specified, or in xml_page_order.txt format if this template is defined. __OCART__ replaced with data from the ocart table in the default format if no template is specified, or in xml_page_ocart.txt format if this template is defined. __SHIPTO__ replaced with data from the addresses table in the default format if no template is specified, or in xml_page_shipto.txt format if this template is defined. __BILLTO__ replaced with data from the addresses table in the default format if no template is specified, or in xml_page_billto.txt format if this template is defined. __CONTACTS__ replaced with data from the contacts table in the default format if no template is specified, or in xml_page_contacts.txt format if this template is defined. xml_page_contacts.txt This template outlines the format of the data that is retrieved from the contacts table. Tags that can exist are __tag__ where tag is the name of any field that is in the contacts table that you wish to be included in the exported file. xml_page_order.txt This template outlines the format of the data that is retrieved from the order table. Tags that can exist are __tag__ where tag is the name of any field that is in the order table that you wish to be included in the exported file. xml_page_shipto.txt This template outlines the format of the data that is retrieved from the addresses table for the ship to address. Tags that can exist are __tag__ where tag is the name of any field that is in the addresses table that you wish to be included in the exported file. xml_page_billto.txt This template outlines the format of the data that is retrieved from the addresses table for the bill to address. Tags that can exist are __tag__ where tag is the name of any field that is in the addresses table that you wish to be included in the exported file. xml_page_ocart.txt This template outlines the format of the data that is retrieved from the ocart table for each item purchased in the order. Tags that can exist are __tag__ where tag is the name of any field that is in the ocart table that you wish to be included in the exported file, as well as __title__ which is retrieved from the things table for each item that is in the order. Example: xml_page_ocart.txt
This would only show the objid and the title for EACH product purchased. You can define any of the above templates as you desire. It will use all templates that are defined, and use default values for the other data. If you do not want to see any data from one of the tables, you can define a template that is completely blank. Then you will not see any data from that template. 4.2.5 Other (HTML) |