article

Shopping Carts made Easier

Email
Submitted on: 1/6/2015 7:04:00 AM
By: Derreck Dean (from psc cd)  
Level: Intermediate
User Rating: By 7 Users
Compatibility: ASP (Active Server Pages)
Views: 457
 
     Explains tactics and some standards on programming e-Commerce applications, such as Shopping Carts.

 
				Developing Smater Web Applications

Here's some general guidelines when developing database-driven applications. I've learned these through experience.

(1) The "Master-Database Technique" is BAD
I developed a shopping cart system that held a lot of its information in a master database (how the site is configured, logins, etc.), and the products, categories, etc. were all kept in a site-specific database. Not only did I do that, I made the admin section global (in a single place) where all clients of the shopping cart systemn could log in and manage their website. In the beginning, this was a great idea; however, it now has its obvious flaws.
[a] What if a customer wants to move to a different hosting provider?
[b] What if the server that the master database resides on is different from the website's database server? If the master DB goes down, so does the website. [c] The biggest problem was custom coding. It could not be done efficiently with the system I had in place. The code got so big and bulky that I am writing new code to replace it.

(2) Adding products to the consumer shopping cart: Direct DB access or Arrays?
When developing shopping carts, there are two general ways of handling how items are stored in the shopping cart. One is handling the products in an array that is held in a session variable. The other is directly putting the items into the database and using a unique identifier to handle the order. Let's look at both options here.

Array Shopping Cart
Pros:
* EXTREMELY fast processing
* Very easy to use
* Uses little memory if done right (don't define a static array like "DIM Cart(7, 9999)", build dynamically using REDIM PRESERVE statements
Cons:
* Unless you build it otherwise, you can't see what people have ordered before they up and leave without finishing

Direct in DB Cart
Pros:
* You can make wishlists or save orders for future visits/references without special programming (the records are already there)
* By use of cookies you can defeat the session timeout of ASP sessions Cons:
* EXTREMELY SLOW (for a full featured cart, you can have a lot of database calls on one page)
* CPU intensive compared to the array method
* Since you have to make some kind of OrderID to refer the records to when they are added to the shopping cart, usually by INSERTing a blank order into the database, you'll find that you'll have a LOT of blank orders which will throw off your IDENTITY column (OrderID).

The array shopping cart is better in this case. Personally, I would prefer to custom write code to do wishlists (not hard) or saving orders for future reference. That's what the Session_OnEnd sub is for!

(3) Product Customization Fields
This was a cool feature I added into my shopping carts. Some shopping carts out there only allowed you to customize certain features, such as Size or Color. I've seen other carts that allow you to do more than that BUT they were slow and bulky. Now, I introduce to you my method of writing product customization. For those of you in the dark here, product customization is letting the consumer choose certain options for his/her desired product. For example, a hat comes in three different colors, 2 different fabrics, and allows for engraved lettering on it. Some carts had a seperate table to keep track of these items in the cart. That's too much work. If you're good with working with Strings and string functions, it's not all that hard, and all you need is a text (nvarhcar) field, or a memo (ntext) field. Here's an example, using the previous defined data about the hat.

Choose Color of Hat:=Black,White,Gray;Choose Fabric:=Suede,Cloth;Up to Three Letters for Engraving:=%text%;

All I did was SPLIT() by the semicolon, and looped through and SPLIT() again by the equalsign to write out my fields. Here's some example code:

DIM Atts
Atts = "Choose Color of Hat:=Black,White,Gray;Choose Fabric:=Suede,Cloth;Up to Three Letters for Engraving:=%text%;"
Heads = SPLIT(Atts, ";")
FOR A = LBOUND(Heads) TO UBOUND(Heads)
   F = SPLIT(Heads(A), "=") ' Splitting header and fields
   Response.Write F(0) ' Write header
   G = SPLIT(F(1), ",") ' Split fields
   IF UCASE(G(0)) = "%TEXT%" THEN
     ' Textfield
     Response.Write "<input type=""text"" name=""whatever"" value="""">"
   ELSE
     Response.Write "<select name=""whatever"">"
     FOR B = 0 TO UBOUND(G)
       Response.Write "<option>" & G(B) & "</option>"
     NEXT
     Response.Write "</select>"
   END IF
NEXT

I was able to name the fields, read them when the form was submitted, stick them into an extra field in my array and later write them into the database. I even assigned pricing, where some options added/subtracted a price from the original price. There's lots of ways you can perform this.

Vote if you like, and I'll post more soon!


Report Bad Submission
Use this form to tell us if this entry should be deleted (i.e contains no code, is a virus, etc.).
This submission should be removed because:

Your Vote

What do you think of this article (in the Intermediate category)?
(The article with your highest vote will win this month's coding contest!)
Excellent  Good  Average  Below Average  Poor (See voting log ...)
 

Other User Comments


 There are no comments on this submission.
 

Add Your Feedback
Your feedback will be posted below and an email sent to the author. Please remember that the author was kind enough to share this with you, so any criticisms must be stated politely, or they will be deleted. (For feedback not related to this particular article, please click here instead.)
 

To post feedback, first please login.