Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Looking for Suggestions

Reply
Thread Tools

Looking for Suggestions

 
 
Jonathan Wood
Guest
Posts: n/a
 
      04-27-2009
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

 
Reply With Quote
 
 
 
 
JM
Guest
Posts: n/a
 
      04-27-2009
> 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



 
Reply With Quote
 
 
 
 
Alexey Smirnov
Guest
Posts: n/a
 
      04-27-2009
On Apr 27, 5:43*pm, "Jonathan Wood" <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Jonathan Wood
Guest
Posts: n/a
 
      04-27-2009
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

"JM" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>> 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
>
>
>


 
Reply With Quote
 
Jonathan Wood
Guest
Posts: n/a
 
      04-27-2009
"Alexey Smirnov" <(E-Mail Removed)> wrote in message
news:37f6e24d-2f39-4de3-bea7-

> 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

 
Reply With Quote
 
Alexey Smirnov
Guest
Posts: n/a
 
      04-28-2009
On Apr 27, 9:41*pm, "Jonathan Wood" <(E-Mail Removed)> wrote:
> "Alexey Smirnov" <(E-Mail Removed)> wrote in message
>
> news:37f6e24d-2f39-4de3-bea7-
>
> > 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


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.
 
Reply With Quote
 
Alexey Smirnov
Guest
Posts: n/a
 
      04-28-2009
On Apr 27, 9:41*pm, "Jonathan Wood" <(E-Mail Removed)> wrote:
> "Alexey Smirnov" <(E-Mail Removed)> wrote in message
>
> news:37f6e24d-2f39-4de3-bea7-
>
> > 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


What database do you have? In SQL Server to run sql automatically you
can use DTS/SSIS
 
Reply With Quote
 
JM
Guest
Posts: n/a
 
      04-28-2009
> 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


 
Reply With Quote
 
Jonathan Wood
Guest
Posts: n/a
 
      04-28-2009
"JM" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

>> 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


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.

>> 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.


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.

>> 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..


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

Thanks!

Jonathan

 
Reply With Quote
 
Jonathan Wood
Guest
Posts: n/a
 
      04-28-2009
"Alexey Smirnov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
looking for suggestions - SEO web site canadafred HTML 21 02-13-2006 02:48 AM
New Java community site - looking for category suggestions gavinjoyce@gmail.com Java 4 01-22-2006 01:37 AM
Looking for suggestions on how to download files from a server. UJ ASP .Net 1 08-23-2005 05:18 PM
Looking for Suggestions =?Utf-8?B?U3lyYWN1c2VDaGVlcg==?= MCSD 2 02-09-2005 01:33 PM
Help esk Suggestions - Best Practices, Tool, ideas, suggestions, etc JohnNews Computer Support 3 06-23-2003 11:20 PM



Advertisments