Who needs shopping carts?

[rodry]

This is just my opinion.

With the existence of tools like MySQL and DBI for PERL, why should a developer consider a packaged shopping cart software, or subscribe to developing a shopping cart solution without a database back end.

Couldn't one just simply store the product numbers of the items in a cookie file, then when the shopper is ready to check out, load them into the query and execute the purchase?

What do you think?

Originally posted as a Categorized Question.

[BBQ]

I agree and disagree! :o)

I agree that one can easily use the method you mentioned to maintain a stateless connection through the use of cookies, but that's a pretty simple Shopping Cart.

A real Shopping Cart should be a cookie-free, stateless and still be persistent. If you should set a cookie, set it just to identify the user, and then create an empty shopping cart that he/she can add products to. This allows you to do more fancy stuff later on such as:
• reports on saved goods
• wishlists
• shared carts
• save on one machine, retreive on another
just to mention a few... It all depends on the shopping model you are looking at.

But as a developer, I would never consider purchasing a shopping cart. IMHO, that's a total overkill. I'd purchase a complete store, but never just the shopping cart package. Its too easy to build one yourself, and get the features you want.

just my R$ 0.02 (Brazilian cents) worth.

[toadi]

Idem

The only time I use is a cookie for identifying the user.
There are more options to do with a db. If you like it or not.
But most companies like to get stats(mostley the sales).

Shopping has all to do with marketing. And nice graf's and charts displaying
all kinds of information... And this information is also important.

Off cource in some smaller cases this isn't really needed. But nontheless it's the best solution!

Actually my firm is specialized in making these kind of websites. For small and large companies.
We build stores, shopping-carts etc... The best is to make a custom one e.g. build one that's got a good engine
and customize it for each customer.

[Anonymous Monk]

Unfortunately a lot of people do not accept cookies (gasp) and being that they don't you would lose them as customers right off of the bat. It is hard to justify losing customers becuase you want to do it an easier way.

[merlyn]

Cookies are clearly not the only solution. Cookies are stripped at some security firewalls, so you'll likely break it for a legitmate user if you do that. See my post on Encrypting or Hiding Certain Info in a URL for the full list of "can" and "don'ts".

[Anonymous Monk]

I only use a cookie if the user wants to add more than one item to the cart. On the "add to cart" button I take them straight to the cart with "check out" as the next option. Only if they want to add more items to I give out a cookie. Since most people only seem to buy one item the system rarely needs to give out cookies.

[sinan]

You can create a shopping cart without using any cookies. You just have to create a user id, and have it sent over and over again with hidden inputs.

As for the shopping information, put it in a DB on your hard disk. The table should have the same user id as the primary key.

Sinan

[Anonymous Monk]

its a far too simplistic view, making a good stateless yet efficient shopping cart involves using a database which has either the inherent ability to store objects like oracle or using a language like java which allows you to serialize objects and store them in databases as instances which can be retreived later. While it s not vastly difficult to do the above. some amount of design constraints are involved. like the design of the cart object. [e-mail]