Shopping Cart

[Rafael Taboada <ka...@gmail.com>]

 Hi dear folks... I'm programming something like a shopping cart. Do u know 
some way to do that? Or a site where I can find some sample code...
  I was thinking about to store beans in session context... But what about 
if the bean is so big??? Will there be any problem with the size???
  I was also thinking about to use one actionform to keep all the data. Of 
course there are some jsps like wizard... But how to keep the actionform in 
a session context?
  Please share ur experience with that.. I'll appreciate if u know some 
sample code or a site...

-- 
Rafael Taboada
Cell : 511-97753290

"No creo en el destino pues no me gusta tener la idea de controlar mi vida"

Re: Shopping Cart

[Rafael Taboada <ka...@gmail.com>]

 Ok, I decided to work with the session context. But I have a problem I 
don't know how to solve it.
  I have a form, inside there's a submit button but there are some buttons 
in order to do extra function like add a new item to the form.
  My problem is I don't how to store in my action the data that the user has 
filled before to press another button different to submit button.
  Because when the user press the submit button, the action receive the form 
and i can work with the data, but how can i know if the user is 
prepopulating extra data before press the submit button?
  I have some link buttons that they do some extra functions inside the 
form...
  Can u know??


-- 
Rafael Taboada
Cell : 511-97753290

"No creo en el destino pues no me gusta tener la idea de controlar mi vida"

Re: Shopping Cart

[Eddie Bush <ea...@swbell.net>]

Rafael,

I agree with Michael that the session can be a good tool to use in this 
case, but you probably don't want to use it exclusively.  It's irresponsible 
for us, as developers to assume that storage is not one of our concerns. 
Each of us have a fiduciary responsibility to our companies and customers. 
Expense control is (or should be) everyone's concern.  Michael may disagree 
with me, but whoever is in charge of budgeting your hardware will probably 
thank you.

Having said that, deciding whether your shopping cart should store 
everything in the session really involves knowing how the cart will be 
used - knowing the business.  If you expect that, on average, people are 
going to add only a few things to their cart at once, you could very easily 
store all the data in the session - and putting the form into session scope 
might be one good way to accomplish this.  If, on the other hand, you expect 
that your users will, on average, put tons of items in their shopping carts 
(hundreds), putting all of your data into the session would be irresponsible 
since your application won't scale very well.  In this case, you'd be better 
served to store only essential information in the session (such as the 
catalog numbers of the items, quantity ... only essential information) and 
grab the other data when the user asks to view their shopping cart.

In general, if you know that your dataset is never going to grow to a large 
size, and its information you need to track for the users entire session, 
session scope is a great place to keep it.  If the dataset is expected to 
be, or will on average be, quite large, you're better off to store only an 
abstraction of the data (the key, for example) in the session and 
re-retrieve the details each time the user wishes to view it.  If you put 
thought into how you construct your queries, and have proper indices 
created, the user experience shouldn't suffer much.

Hope that helps!

Eddie Bush

----- Original Message ----- 
From: "Michael Jouravlev" <jm...@gmail.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>; "Rafael Taboada" 
<ka...@gmail.com>
Sent: Friday, May 27, 2005 1:41 PM
Subject: Re: Shopping Cart


On 5/27/05, Rafael Taboada <ka...@gmail.com> wrote:
>  Hi dear folks... I'm programming something like a shopping cart. Do u 
> know
> some way to do that? Or a site where I can find some sample code...
>   I was thinking about to store beans in session context... But what about
> if the bean is so big??? Will there be any problem with the size???

Rafael, I guess you know my opinion on this ;) I prefer to store
stateful objects on server. If it is not in the session, than it is in
the database. But I do not like to pass stuff around in
request/response fields.



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0521-4, 05/27/2005
Tested on: 5/28/2005 12:16:35 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com




---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Shopping Cart

[Rafael Taboada <ka...@gmail.com>]

 So, do u agree that the best way to store temporary beans is in the session 
context??? Is it the right approach?
  I changed the scope of the action mapping to session... But I saw that 
reset method is called each time a method inside the action is called... I 
work with dispatchaction..


-- 
Rafael Taboada
Cell : 511-97753290

"No creo en el destino pues no me gusta tener la idea de controlar mi vida"

Re: Shopping Cart

[Michael Jouravlev <jm...@gmail.com>]

On 5/27/05, Rafael Taboada <ka...@gmail.com> wrote:
>  Hi dear folks... I'm programming something like a shopping cart. Do u know
> some way to do that? Or a site where I can find some sample code...
>   I was thinking about to store beans in session context... But what about
> if the bean is so big??? Will there be any problem with the size???

Rafael, I guess you know my opinion on this ;) I prefer to store
stateful objects on server. If it is not in the session, than it is in
the database. But I do not like to pass stuff around in
request/response fields.

Session size? My strong opinion that this is not an application
problem :), this is a hardware/appserver problem. I would rather get
more memory or get a replication software if I need, but I do not want
session size to affect my design decisions. You can offset session
size issues with better hardware/appserver, but you cannot work around
HTTP. I feel that the only proper thing is to bend over to HTTP spec
and to use its features and quirks, or otherwise the user experience
will suck big time.

It is so much easier when you have state in one place, and your pages
are generated according to _current_ state. The point is, that each
time you submit, or go back, or forward, or refresh, you do not
navigate to a particular _page_, you navigate to an _action_. The
action can be intelligent enough to understand if application state
was changed, and to show a page with appropriate content, like "your
cart was already processed and disposed". This is the beauty of front
controller framework like Struts, where an action can respond with any
content it wants, but for a browser it is just the same page which
comes from an action URL. If you mark your pages as non-cachable, they
will always be reloaded, and you will be able to always provide a page
consistent with server state. In this case you would not care about
back button and double submits.

Right, some sucky browsers do not reload page even if it is marked as
non-cachable (Opera must die, they don't want to hear about reacting
to "no-store" like MSIE and Mozilla). But even in this case, if you go
back and resubmit a stale page, the server state will be already in
updated state, the corresponding object will be removed, so you will
easily see the discrepance between the page and the server state.

>   I was also thinking about to use one actionform to keep all the data. Of
> course there are some jsps like wizard... But how to keep the actionform in
> a session context?

How about setting its "scope" to "session" in the action mapping definition?

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org