Yep I am thinking unless someone has a better idea this is just going to have to be the way we do it.
We can let them build a cart by assigning a user session ID to the cart till they login or sign up and then putting in their customer ID. on 5/11/06 10:44, Jason Pamental at [EMAIL PROTECTED] wrote: > Dan - > > I think you've come across the biggest issue - public access computers > and session tracking. I don't think there's a really good way to trap > for that - but it might be a site-user and your-client education > opportunity: only allow saved carts for registered users. It's easy > enough using your logic to take a cart from a non-logged-in user and > save it once they sign in or sign up - but I think it would need to be > within a single browsing session. This does a couple of things - it > keeps you from having to store a lot of stuff that may never be > retrieved, but also provides incentive for site users to create an > account. This in turn generates much more meaningful marketing data on > potential customers even before they actually buy anything. When a > company is footing the bill for creating and maintaining a website, it's > a small price to as the site user to 'pay' (sign up for an account - > just keep the process simple and short!) for the convenience of having > their cart preserved. I think that when put into that context > (explaining the return on investment (or lack thereof)) you may find > that your client is pretty happy with the solution you've already > created. I think that's certainly on par with what other major shopping > sites do. > > Good luck with it- > > Jason > > Jason Pamental > Director of Web Services > North Sails > > Office: 401.643.1415 > Fax: 401.643.1420 > Mobile: 401.743.4406 > Email: [EMAIL PROTECTED] > > > > > Dan Stein wrote: >> Cart Conundrum >> >> I am building a cart system for a client who wants people to be able to add >> items to a cart and have the cart saved even if they don¹t login. To buy >> anything they ultimately will have to sign up and be logged in. >> >> We came up with this bit of logic, which works well to a point >> >> When they come to a site we set a visitor ID cookie and then as they add >> things to their cart we insert that visitor ID. Once they log in we loop >> through any cart items with that visitor ID and add in their customer ID. >> >> So now they come back but from a different browser. There is not much we can >> do here. They get assigned another visitor ID and the cart is empty. But as >> soon as they log in we are able to add their customer ID and reset the visor >> ID cookie to match the other browser so now we have consolidated their cart. >> >> This works really nicely. >> >> But, as I thought about the users and what they might do. I realized this >> would fail or at least get really confused if the user logs in from a public >> computer like a library. >> >> So I need to rethink this and I wonder how other people are handling this. >> >> I am open and interested in hearing peoples thoughts and how they deal with >> this issue. >> >> It seems it would make a useful thread. >> >> > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > -- Dan Stein FileMaker 7 Certified Developer Digital Software Solutions 799 Evergreen Circle Telford PA 18969 Land: 215-799-0192 Cell: 610-256-2843 Fax 413-410-9682 FMP, WiTango, EDI,SQL 2000, MySQL, CWP [EMAIL PROTECTED] www.dss-db.com 'I wonder why we say that people are of different "races". It seems to me, we're all running at the same speed and heading towards the same destination. The only "winners" are the ones who've made the world a better place for having been here.' >From for Better or Worse 2/28/2006 ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
