[thelist] Re: Which way is best? (was: Re: Homemade Shopping Cart)

[Kevin Martin]

Quoth Rob Smith <rob.smith at THERMON.com>...

> > I'll show you mine if you show me yours.  :-)
> 
> Well, I would if I could. The sensitivity of the information is pretty
> sensitive.

Unless you're in the habit of using variables names such as 
"$I_HATE_MY_BOSS" I can't imagine how sensitive information
appears in your code...?  Perhaps I misunderstand.

> A) Do you store these items in a temporary table? Once the order is
> complete, do you then go to that list and mark out the items on the real
> table?

Seems reasonable.  Think it through; you are engaging in a transaction,
by which we mean you have to complete the operation or "roll it back."
If you take the payment you must deliver the goods.

> B) Do you store your information in cookies, by which not all browsers
> support these? nor are locked down computers accept them?

PHP is quite clever about that; it uses cookies if it can, but it
has a fallback of (hidden) session variables.  They've been transparent
to me as the developer and a pleasure to use.

> C) Do you store your order in session variables and hope that your customer
> doesn't take too long to shop around your store?

A "shopping bag" table seems like a better approach.  The session ID
has enough work to do.  PHP will use them if it has to, though.

> D) Do you use the "HttpSessionBindingListener, so if the transaction isn't
> completed before the standard session timeout, (that) all products are then
> returned to inventory as part of discarding the cart."

Sounds like something I'd like to investigate further.  I have the
code I need to run, but could use that (or something else) to trigger
it.

> E) Do I go ahead and assume that if they add that unique item to the cart
> that it is considered sold at that point? But as Jay had mentioned, their
> cell phone rings and the have to bolt out of the store. Then some time later
> an employee or program returns the item back to the shelf?

It makes a little difference whether you're dealing with "fungible" 
items, where one box of bolts is as good as any other, or unique
items like a signed Mickey Mantle baseball card.  As H. noted, I'm
using a SKU and a stock counter, even though in my demo store most
of the items ARE one of a kind.  The concept of a SKU is that it has
to be "unique enough."  If two items have the same SKU, you can give
the customer either one and you've completed your half of the sale.

If I have a unique item, I give it a unique SKU and set its stock
counter to "1" -- and that's good enough.  That way the store has
the flexibility to represent one-of-a-kind items, but I can also
handle a carton with a dozen copies of the same book without 
changing any code.  It reduces the pressure a lot if you have
enough inventory to let a few "GI Joes" run around the aisles.

> Obviously there is a difference of opinion here. Keep in mind that this is
> only the tip of the ice burg of shopping cart implementations.

Oh, yeah. :-)  I haven't turned on the "roboclerk" stock-boy function
yet, the one to put things back on the shelf -- I'm still doing that
by hand.  It has given me a dark view of the typical visitor to my
working demo page; very few of them bother to go all the way to
checkout.
 
> Curiously thinking, are you a program?

More of a programmer than a web designer, yes. I've got twenty
years of COBOL under my belt, switched to Unix administration
quite a while back, and in both careers learned that pessimists
are rarely disappointed. :-)

> But the underlying question is which way is best?

Define the problem; let the answers present themselves.