Re: [OT] Shopping cart best practices - Cookie, HttpSession or DB
Storing a few bits and pieces in a session is all storing a cart will do anyway. While I can see why some folks would consider it a clear benefit to save all carts to the db , i don't. But that can be layered on afterwards, especially with handy packages like beanutils. Given that most the folks who know about these things say the biggest bottleneck is the DB stuff, I'd want to approach this in a manner where i could move stuff around. When you get to testing you see how many sessions you can have running. The storage of an array of id's would be a nice solution if things start to look bloated, but doing this before would be stamping on problems that aren't there yet. If I had to walk into someone's code i'd prefer if carts had appropriate properties and the products in the cart were also product like. Cart cart = (Cart) session.getAttribute("cart"); Product product = new Product(); BeanUtils.copyProperties( product , theForm.get("product") ); cart.addProduct(product); If i had to pull a bunch of keys and indices from an array I'd be dummy spitting i think. Cheers Mark On Thursday, August 21, 2003, at 11:07 PM, Adam Hardy wrote: I think the issue of using up server memory with lots of shopping carts in the session is worth thinking about. It's just a question of maths - how much memory have you got, what is the peak number of users envisaged, how much stuff are you going to store in the session? even then I think some app servers swap out sessions to the hard drive when memory is low. You don't need more than an array of item ids and quantities, methinks, so it should be small. On 08/21/2003 06:38 PM Greg Ludington wrote: 1. Store your cart in session, and when that all works. For everyone. Gets to the checkout and funds are exchanged. While I agree with the previous posters who said that it would make your life easier if you can require login, if you absolutely need to save carts of users regardless of login status, you might consider having your Cart object impelment javax.servlet.http.HttpSessionBindingListener. Objects implementing this interface are notified when they are bound to or unbound from (either explicitly or by the session itself expiring/invalidated) a session, and can perform tasks at these times. In your case, when your Cart object is unbound you would save its contents to your database. (Conversely, when you first bind a Cart object to a session, you can check the database and refresh its contents, if any.) Nothing about this approach prohibits you from saving Cart information at other appropriate times -- user logins, purchases, and the like -- this approach just allows you the ability to store information, like cart contents, at the end of a client session. -Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Shopping cart best practices - Cookie, HttpSession or DB
Thanks Adam, Makes sense, Appreciate it, Brian -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 21 August 2003 22:07 To: Struts Users Mailing List Subject: Re: [OT] Shopping cart best practices - Cookie, HttpSession or DB I think the issue of using up server memory with lots of shopping carts in the session is worth thinking about. It's just a question of maths - how much memory have you got, what is the peak number of users envisaged, how much stuff are you going to store in the session? even then I think some app servers swap out sessions to the hard drive when memory is low. You don't need more than an array of item ids and quantities, methinks, so it should be small. On 08/21/2003 06:38 PM Greg Ludington wrote: >>1. Store your cart in session, and when that all works. For everyone. >>Gets to the checkout and funds are exchanged. > > > While I agree with the previous posters who said that it would make your > life easier if you can require login, if you absolutely need to save > carts of users regardless of login status, you might consider having > your Cart object impelment > javax.servlet.http.HttpSessionBindingListener. Objects implementing > this interface are notified when they are bound to or unbound from > (either explicitly or by the session itself expiring/invalidated) a > session, and can perform tasks at these times. > > In your case, when your Cart object is unbound you would save its > contents to your database. (Conversely, when you first bind a Cart > object to a session, you can check the database and refresh its > contents, if any.) Nothing about this approach prohibits you from > saving Cart information at other appropriate times -- user logins, > purchases, and the like -- this approach just allows you the ability to > store information, like cart contents, at the end of a client session. > > -Greg > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Shopping cart best practices - Cookie, HttpSession or DB
Thanks for the info Greg, Another good idea :-) I appreciate it, Brian -Original Message- From: Greg Ludington [mailto:[EMAIL PROTECTED] Sent: 21 August 2003 16:39 To: 'Brian McSweeney'; 'Struts Users Mailing List' Subject: RE: [OT] Shopping cart best practices - Cookie, HttpSession or DB >1. Store your cart in session, and when that all works. For everyone. >Gets to the checkout and funds are exchanged. While I agree with the previous posters who said that it would make your life easier if you can require login, if you absolutely need to save carts of users regardless of login status, you might consider having your Cart object impelment javax.servlet.http.HttpSessionBindingListener. Objects implementing this interface are notified when they are bound to or unbound from (either explicitly or by the session itself expiring/invalidated) a session, and can perform tasks at these times. In your case, when your Cart object is unbound you would save its contents to your database. (Conversely, when you first bind a Cart object to a session, you can check the database and refresh its contents, if any.) Nothing about this approach prohibits you from saving Cart information at other appropriate times -- user logins, purchases, and the like -- this approach just allows you the ability to store information, like cart contents, at the end of a client session. -Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Shopping cart best practices - Cookie, HttpSession or DB
I think the issue of using up server memory with lots of shopping carts in the session is worth thinking about. It's just a question of maths - how much memory have you got, what is the peak number of users envisaged, how much stuff are you going to store in the session? even then I think some app servers swap out sessions to the hard drive when memory is low. You don't need more than an array of item ids and quantities, methinks, so it should be small. On 08/21/2003 06:38 PM Greg Ludington wrote: 1. Store your cart in session, and when that all works. For everyone. Gets to the checkout and funds are exchanged. While I agree with the previous posters who said that it would make your life easier if you can require login, if you absolutely need to save carts of users regardless of login status, you might consider having your Cart object impelment javax.servlet.http.HttpSessionBindingListener. Objects implementing this interface are notified when they are bound to or unbound from (either explicitly or by the session itself expiring/invalidated) a session, and can perform tasks at these times. In your case, when your Cart object is unbound you would save its contents to your database. (Conversely, when you first bind a Cart object to a session, you can check the database and refresh its contents, if any.) Nothing about this approach prohibits you from saving Cart information at other appropriate times -- user logins, purchases, and the like -- this approach just allows you the ability to store information, like cart contents, at the end of a client session. -Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Shopping cart best practices - Cookie, HttpSession or DB
>1. Store your cart in session, and when that all works. For everyone. >Gets to the checkout and funds are exchanged. While I agree with the previous posters who said that it would make your life easier if you can require login, if you absolutely need to save carts of users regardless of login status, you might consider having your Cart object impelment javax.servlet.http.HttpSessionBindingListener. Objects implementing this interface are notified when they are bound to or unbound from (either explicitly or by the session itself expiring/invalidated) a session, and can perform tasks at these times. In your case, when your Cart object is unbound you would save its contents to your database. (Conversely, when you first bind a Cart object to a session, you can check the database and refresh its contents, if any.) Nothing about this approach prohibits you from saving Cart information at other appropriate times -- user logins, purchases, and the like -- this approach just allows you the ability to store information, like cart contents, at the end of a client session. -Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Shopping cart best practices - Cookie, HttpSession or DB
Hi Mark, Actually this is EXACTLY what I was thinking of doing. The one problem that I had with this idea is that I was a bit worried about filling up the session object with lots of stuff. Is this not really a problem? Cheers, Brian -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: 21 August 2003 16:02 To: Struts Users Mailing List Subject: Re: [OT] Shopping cart best practices - Cookie, HttpSession or DB I haven't any tech input, but I've an idea how I'd stagger the development.I'd forget about cookies and db's at first, save them for a later stage. 1. Store your cart in session, and when that all works. For everyone. Gets to the checkout and funds are exchanged. 2. Create a login where clever stuff like saving your objects to db's goes on. 3. Then once you've a logged in user start thinking about when to save the cart. if(user.isLogged()) { //or however your api lets you do it cart.save(); } None of what I've said is ground breaking, but It does avoid messing with cookies, up to this stage. When the user logs in s/he gets his/her cart back. 4. I guess the final stage could be to do the cookie stuff, so users are logged in as soon as they get to the site. And thus the retrieval of the cart also, as its already in place integration would be smooth. Don't know who useful this is, but there's nothing to offer in terms of the actual mechanisms in play. But by getting folks paying asap, the extras don't become show stoppers. Cheers Mark On Thursday, August 21, 2003, at 02:33 PM, Brian McSweeney wrote: > Hi Vic, > > Definitely life would be easier, but I don't think it's as good :-) > > Thanks though, > Brian > > -Original Message- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Vic Cekvenich > Sent: 21 August 2003 02:30 > To: [EMAIL PROTECTED] > Subject: Re: [OT] Shopping cart best practices - Cookie, HttpSession or > DB > > I think you'd make your life easier if your required login. > .V > > Brian McSweeney wrote: > >> Hi all, >> >> Quick question. I want to implement a shopping cart. I know this has >> been done a million times in a million open source projects however I >> have a few questions, and seeing as everyone in here seems so >> knowledgeable. >> >> What I'd like: >> >> 1) User can add to shopping cart without having to check in. (checkout >> requires login). >> >> 2) User can leave the site and un-checked out shopping cart data will >> remain. >> >> The options I have to implement the shopping cart: >> >> a) Cookies - satisfies 1 and 2, but assumes user doesn't turn > off >> cookies >> >> b) HttpSession object - satisfies 1, but not 2 >> >> c) Database shopping cart object - satisfies 2, but not 1. >> >> I'd like to know, >> >> a) am I basically correct with these assumptions. >> b) What would people recommend based on their experience. >> c) any struts open source project that might have this? >> >> Thanks very much, >> Brian >> >> >> >> > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Shopping cart best practices - Cookie, HttpSession or DB
I haven't any tech input, but I've an idea how I'd stagger the development.I'd forget about cookies and db's at first, save them for a later stage. 1. Store your cart in session, and when that all works. For everyone. Gets to the checkout and funds are exchanged. 2. Create a login where clever stuff like saving your objects to db's goes on. 3. Then once you've a logged in user start thinking about when to save the cart. if(user.isLogged()) { //or however your api lets you do it cart.save(); } None of what I've said is ground breaking, but It does avoid messing with cookies, up to this stage. When the user logs in s/he gets his/her cart back. 4. I guess the final stage could be to do the cookie stuff, so users are logged in as soon as they get to the site. And thus the retrieval of the cart also, as its already in place integration would be smooth. Don't know who useful this is, but there's nothing to offer in terms of the actual mechanisms in play. But by getting folks paying asap, the extras don't become show stoppers. Cheers Mark On Thursday, August 21, 2003, at 02:33 PM, Brian McSweeney wrote: Hi Vic, Definitely life would be easier, but I don't think it's as good :-) Thanks though, Brian -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Vic Cekvenich Sent: 21 August 2003 02:30 To: [EMAIL PROTECTED] Subject: Re: [OT] Shopping cart best practices - Cookie, HttpSession or DB I think you'd make your life easier if your required login. .V Brian McSweeney wrote: Hi all, Quick question. I want to implement a shopping cart. I know this has been done a million times in a million open source projects however I have a few questions, and seeing as everyone in here seems so knowledgeable. What I'd like: 1) User can add to shopping cart without having to check in. (checkout requires login). 2) User can leave the site and un-checked out shopping cart data will remain. The options I have to implement the shopping cart: a) Cookies - satisfies 1 and 2, but assumes user doesn't turn off cookies b) HttpSession object - satisfies 1, but not 2 c) Database shopping cart object - satisfies 2, but not 1. I'd like to know, a) am I basically correct with these assumptions. b) What would people recommend based on their experience. c) any struts open source project that might have this? Thanks very much, Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Shopping cart best practices - Cookie, HttpSession or DB
Hi Vic, Definitely life would be easier, but I don't think it's as good :-) Thanks though, Brian -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Vic Cekvenich Sent: 21 August 2003 02:30 To: [EMAIL PROTECTED] Subject: Re: [OT] Shopping cart best practices - Cookie, HttpSession or DB I think you'd make your life easier if your required login. .V Brian McSweeney wrote: > Hi all, > > Quick question. I want to implement a shopping cart. I know this has > been done a million times in a million open source projects however I > have a few questions, and seeing as everyone in here seems so > knowledgeable. > > What I'd like: > > 1) User can add to shopping cart without having to check in. (checkout > requires login). > > 2) User can leave the site and un-checked out shopping cart data will > remain. > > The options I have to implement the shopping cart: > > a) Cookies - satisfies 1 and 2, but assumes user doesn't turn off > cookies > > b) HttpSession object - satisfies 1, but not 2 > > c) Database shopping cart object - satisfies 2, but not 1. > > I'd like to know, > > a) am I basically correct with these assumptions. > b) What would people recommend based on their experience. > c) any struts open source project that might have this? > > Thanks very much, > Brian > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Shopping cart best practices - Cookie, HttpSession or DB
Hey Tero, Thanks for the reply. Really appreciate the tips. Brian -Original Message- From: Paananen, Tero [mailto:[EMAIL PROTECTED] Sent: 20 August 2003 18:36 To: 'Struts Users Mailing List' Subject: RE: [OT] Shopping cart best practices - Cookie, HttpSession or DB > The options I have to implement the shopping cart: > > a) Cookies - satisfies 1 and 2, but assumes user > doesn't turn off > cookies > > b) HttpSession object - satisfies 1, but not 2 > > c) Database shopping cart object - satisfies 2, but not 1. > > I'd like to know, > > a) am I basically correct with these assumptions. > b) What would people recommend based on their experience. > c) any struts open source project that might have this? Use a combination of a), b) and c) :) Store an identifier to the shopping cart in session (security implications here...make sure you don't code an unsecure app), store the shopping cart itself in db, use session cookies (or URL rewriting) to identify, which session the user requests are associated to (this is done automatically by your servlet container). I'm sure you can do this in multiple ways, but that's how I would do it. -TPP - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Shopping cart best practices - Cookie, HttpSession or DB
I think you'd make your life easier if your required login. .V Brian McSweeney wrote: Hi all, Quick question. I want to implement a shopping cart. I know this has been done a million times in a million open source projects however I have a few questions, and seeing as everyone in here seems so knowledgeable. What I'd like: 1) User can add to shopping cart without having to check in. (checkout requires login). 2) User can leave the site and un-checked out shopping cart data will remain. The options I have to implement the shopping cart: a) Cookies - satisfies 1 and 2, but assumes user doesn't turn off cookies b) HttpSession object - satisfies 1, but not 2 c) Database shopping cart object - satisfies 2, but not 1. I'd like to know, a) am I basically correct with these assumptions. b) What would people recommend based on their experience. c) any struts open source project that might have this? Thanks very much, Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Shopping cart best practices - Cookie, HttpSession or DB
> The options I have to implement the shopping cart: > > a) Cookies - satisfies 1 and 2, but assumes user > doesn't turn off > cookies > > b) HttpSession object - satisfies 1, but not 2 > > c) Database shopping cart object - satisfies 2, but not 1. > > I'd like to know, > > a) am I basically correct with these assumptions. > b) What would people recommend based on their experience. > c) any struts open source project that might have this? Use a combination of a), b) and c) :) Store an identifier to the shopping cart in session (security implications here...make sure you don't code an unsecure app), store the shopping cart itself in db, use session cookies (or URL rewriting) to identify, which session the user requests are associated to (this is done automatically by your servlet container). I'm sure you can do this in multiple ways, but that's how I would do it. -TPP - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]