Looking for Suggestions

[Jonathan Wood]

I'm implementing shopping cart functionality on a Website.

In some cases, the products will be selected on another site. The product ID
will be posted to my site, which will look the product up in a database, and
allow the user to purchase it.

That is simple enough. But it would be nice to allow the user to return to
the original site to add even more products to the shopping cart before
checking out (like Americart does). I'm trying to determine the best way to
track the products in the shopping cart while the user is back at the
original site selecting more objects.

If only a single product could be checked out, I would simply store the
information in the session object. But I'm unsure how long this would be
maintained while the user is back at the original site selecting another
project. I'd prefer not to use the database for this because the data is
very temporary and may need to be discarded if the user does not return. The
only other option are cookies, which I haven't really used before.

Has anyone done anything like this? I'd appreciate any suggestions.

Thanks.

Jonathan

 

[JM]

I'd prefer not to use the database for this because the data is very

temporary and may need to be discarded if the user does not return. The
only other option are cookies, which I haven't really used before.

Actually, it would seem that a combination would work best. I think I'd
create a table with the absolute minimum required to remember the items
that were added to the cart. Something like the item ID, session ID (or
some other unique identifier) and date. From there, I'd try the following..

If a person adds items to the cart:
//--
Set a cookie with the date and session ID
Add items to some sort of temporary session object (array, list etc..)
If they actually convert (checkout) delete the cookie, clear the session
object
If the session times out, stash the item(s) info in the above mentioned
table
Purge items from table after 14 days, 30 days etc..

If a person adds items to the cart, leaves and then returns:
//--
Check for a cookie and grab the session ID and date
Check the table for items that match
If they exist, re-populate the cart, otherwise repeat from above


One drawback I see is that you can't be sure if the person that's seeing the
re-populated cart is the same one that originally put the items there. It
could be a different person using the same computer with the same account
on the same website.

And, cookies are not hard to use.

Just some thoughts..

John

 

[Guest]

I'm implementing shopping cart functionality on a Website.

In some cases, the products will be selected on another site. The product ID
will be posted to my site, which will look the product up in a database, and
allow the user to purchase it.

That is simple enough. But it would be nice to allow the user to return to
the original site to add even more products to the shopping cart before
checking out (like Americart does). I'm trying to determine the best way to
track the products in the shopping cart while the user is back at the
original site selecting more objects.

If only a single product could be checked out, I would simply store the
information in the session object. But I'm unsure how long this would be
maintained while the user is back at the original site selecting another
project. I'd prefer not to use the database for this because the data is
very temporary and may need to be discarded if the user does not return. The
only other option are cookies, which I haven't really used before.

Has anyone done anything like this? I'd appreciate any suggestions.

Thanks.

Jonathan

Cookies are limited in size but if you don't have very long product
ids it might work.

The database approach might be useful for analytics purposes - to see
how many visitors put something in the cart but do not come back.

 

[Jonathan Wood]

Thanks for the ideas. I wonder if I might pick at the specifics a bit...

First, is there a way to detected when the temporary session object expires
in order to write it to the database?

Also, if I'm not worried about hanging on to the information for longer than
15 or 20 minutes, do you think it's necessary to use the database? I guess
the main thing I'm unclear on is how long the session object is maintained
and if the session object is maintained when the user leaves or is
redirected to another site and then returns. Thinking about, I guess the
answer to the second issue is yes since, the site has no idea if the user is
at another site or still reading a page from my site.

As far as detecting a different user on the same computer, the only way I
know to address that is to require the user to log in. And, for me, that's
not a good requirement to throw up at someone who is about to give you some
money. <g>

Thanks again.

Jonathan

 

[Jonathan Wood]

Cookies are limited in size but if you don't have very long product
ids it might work.

They are regular integer IDs and I'd need at least the quantity as well.
However, there could be any number of items in the shopping cart so I'm not
sure how that would be handled.

The database approach might be useful for analytics purposes - to see
how many visitors put something in the cart but do not come back.

I agree. And also for troubleshooting any issues where users say they placed
an order but the process broke down somewhere.

Parts of ASP.NET I have a good handle but as you can see there are areas
where I'm not real clear. Does .NET provide an ID that could be used in a
database to uniquely identify a user (or at least the user's computer)?
Also, if I want the data to expire after a couple of days, do I need to do
this manually or is there a way to do that automatically?

Thanks.

Jonathan

 

[Guest]

They are regular integer IDs and I'd need at least the quantity as well.
However, there could be any number of items in the shopping cart so I'm not
sure how that would be handled.


I agree. And also for troubleshooting any issues where users say they placed
an order but the process broke down somewhere.

Parts of ASP.NET I have a good handle but as you can see there are areas
where I'm not real clear. Does .NET provide an ID that could be used in a
database to uniquely identify a user (or at least the user's computer)?
Also, if I want the data to expire after a couple of days, do I need to do
this manually or is there a way to do that automatically?

Thanks.

Jonathan

Jonathan,

I think you still need to set cookies. When user put something in the
cart you add order to the database table, assign a new unique orderid
(using database functionality) and set that orderid to client cookies.
You can set how long cookies are valid (e.g. 2 days) to keep orderid
if user closed browser window or returned to original site. If user
came again, you will check if cookies exist and if yes, and orderid is
valid you would add a new article to existing order, if not, you will
create a new order. After check-out you have to clean client cookies.
That's basically all.

You can't uniquely identify a user without any additional information
such as username or email address. You can get an IP address but this
is not unique feature and it makes no sense to use it if client accept
cookies. BUT it could be a situation where user does not accept
cookies. This can be checked once you set orderid. To make this really
good working for all, you can either show a message that cookies are
required to order more than one product, or you can grab the client IP
+ name and version of the browser and put that information to the
order table. When that user comes again, you would check cookies
(nothing there), than you would check IP and browser (an order exists)
and you will show the existing shopping cart.

Hope this helps.

 

[Guest]

They are regular integer IDs and I'd need at least the quantity as well.
However, there could be any number of items in the shopping cart so I'm not
sure how that would be handled.


I agree. And also for troubleshooting any issues where users say they placed
an order but the process broke down somewhere.

Parts of ASP.NET I have a good handle but as you can see there are areas
where I'm not real clear. Does .NET provide an ID that could be used in a
database to uniquely identify a user (or at least the user's computer)?
Also, if I want the data to expire after a couple of days, do I need to do
this manually or is there a way to do that automatically?

Thanks.

Jonathan

What database do you have? In SQL Server to run sql automatically you
can use DTS/SSIS

 

[JM]

Thanks for the ideas. I wonder if I might pick at the specifics a bit...

First, is there a way to detected when the temporary session object
expires in order to write it to the database?

Lots of info here:

http://aspalliance.com/520

Also, if I'm not worried about hanging on to the information for longer
than 15 or 20 minutes, do you think it's necessary to use the database?

No. The only time I'd even touch the database would be if, after reading the
cookie, it indicates that the user is returning or the session times out and
there
are items still in the cart.

As far as detecting a different user on the same computer, the only way I
know to address that is to require the user to log in.

I'd only offer a login option if the person were a returning customer that's
already ordered something. For that, you could set a cookie and store just
the relevant user info in a DB table for later recall. When the user log's
back in, you could welcome them back with a personalized greeting and
auto-fill their previous shipping address, etc..

John

 

[Jonathan Wood]

Lots of info here:

http://aspalliance.com/520

Thanks for the link. I was a little confused, however. The article mentioned
Session_OnEnd, which I had seen and forgot about, but then goes on to
discuss a completely different technique without really saying why
Session_OnEnd wasn't used.

No. The only time I'd even touch the database would be if, after reading
the
cookie, it indicates that the user is returning or the session times out
and there
are items still in the cart.

Well, I'm considering not touching the database unless the user checks out.
If the session times out, then they'll need to select the product again. I
may modify this behavior in the future but it appears the default session
lasts 20 minutes and I can increase that if needed.

I'd only offer a login option if the person were a returning customer
that's
already ordered something. For that, you could set a cookie and store just
the relevant user info in a DB table for later recall. When the user log's
back in, you could welcome them back with a personalized greeting and
auto-fill their previous shipping address, etc..

Yeah, maybe in the future but the login option is just not important to me
at this point in time.

Thanks!

Jonathan

 

[Jonathan Wood]

I think you still need to set cookies. When user put something in the
cart you add order to the database table, assign a new unique orderid
(using database functionality) and set that orderid to client cookies.

Can you clarify this? Why can't I just use the session object, and then go
to the database only if the user checks out? I realize this only gives them
around 20 minutes but I think that is enough for my current needs. What
would a cookie add to this?

What database do you have? In SQL Server to run sql automatically you
can use DTS/SSIS

SQL Server 2005; however, my site runs on a shared hosting server and I have
limits on what I can do with SQL.

Thanks.

Jonathan

 

[Guest]

Can you clarify this? Why can't I just use the session object, and then go
to the database only if the user checks out? I realize this only gives them
around 20 minutes but I think that is enough for my current needs. What
would a cookie add to this?


SQL Server 2005; however, my site runs on a shared hosting server and I have
limits on what I can do with SQL.

Thanks.

Jonathan

You can use Session, you may even set more than 20 min by using
settings in the web.config file. The only problem here may be IIS
configuration, because of shared hosting. I was simply thinking about
cookies because you can set them to expire when the browser session
ends (e.g. for 2 days)

 

[Jonathan Wood]

Thanks for the clarification. I need to get this thing working by the 5th
due to my circumstances. So I have to piece this together. Then, later on, I
may refine it and look at some of the things you are suggesting.

Thanks again

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
http://www.softcircuits.com/blog/

Can you clarify this? Why can't I just use the session object, and then go
to the database only if the user checks out? I realize this only gives
them
around 20 minutes but I think that is enough for my current needs. What
would a cookie add to this?


SQL Server 2005; however, my site runs on a shared hosting server and I
have
limits on what I can do with SQL.

Thanks.

Jonathan

You can use Session, you may even set more than 20 min by using
settings in the web.config file. The only problem here may be IIS
configuration, because of shared hosting. I was simply thinking about
cookies because you can set them to expire when the browser session
ends (e.g. for 2 days)

 

[Guest]

Thanks for the clarification. I need to get this thing working by the 5th
due to my circumstances. So I have to piece this together. Then, later on, I
may refine it and look at some of the things you are suggesting.

Thanks again

--
Jonathan Wood
SoftCircuits Programminghttp://www.softcircuits.comhttp://www.softcircuits.com/blog/






You can use Session, you may even set more than 20 min by using
settings in the web.config file. The only problem here may be IIS
configuration, because of shared hosting. I was simply thinking about
cookies because you can set them to expire when the browser session
ends (e.g. for 2 days)

Great! Let me know if you would have any questions