Emilia Ipate wrote:
Al, your solution is good, except for one thing: what do you do if the
user leaves the application at step2? You will have in DB all the items
the user checked, but they are no longer necessary....
Emilia
-----Original Message-----
From: Albert L. Sapp [mailto:[EMAIL PROTECTED]
Sent: vrijdag 9 juni 2006 16:20
To: Struts Users Mailing List
Subject: Re: best way to send parameters through more requests
Emilia Ipate wrote:
Hello, all!
Is there a solution besides using session, to send some request
parameters from one request to another?
I would like to implement something like a shopping cart (a
functionality which needs about4-5 steps) and I do not want to store
the objects in the session (it is alread too big)!
So, do you have any ideas?
Kind regards,
Emilia
-----------------------------------------------------------------------
-
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Emilia,
Wanted so what everyone had to say before I dropped in my 2 cents. The
only thing we keep in session is the userID and the unitID for where
they are shopping. This happens in step 1. In step 2, we query the db
to see if they already have shopping cart items from a previous trip to
the storeroom. This step is repeated over and over again as they add
items to their cart. They can add, delete or update an item from this
jsp and are always returned to it. Finally in step 3, they say ok check
me out and we collect the account information we need, create the
accounting transactions, update stock levels, remove the shopping cart
items and give them a chance to print out a listing of their purchases.
The 2 session attributes are cleared and we go back to the jsp where the
next person enters their userID.
3 steps with one of them being repeated. We went with the db approach
because we had to try and capture the items a person said they were
taking in case they give a invalid account or simply get too rushed and
leave without completing the shopping process. Believe me, that happens
more than we like.
I hope this was helpful.
Al
---------------------------------------------------------------------
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]
Emilia,
That is the point for us. This application is used in the storeroom to
allow a user to enter the stock they are taking out of the storeroom.
Granted we could have people walk out with stock and not even enter it,
but, if they do enter it, we want to be able to contact them and ask
what they did with the stock. Did they put it back? Did they take and
forget to checkout? Did they take it and the account they used come
back as invalid? Then, the storekeeper can either complete the checkout
or clear the shopping cart for the user.
We have some indication available to our storekeepers that some activity
has taken place and contact information to use to follow up with. I
mean we are relieve them of the data entry they were doing. They just
have a new job of following up on checkouts not performed. Our next
step is to allow for ordering of items for delivery or pickup and using
the shopping cart to build the pick list for the storekeepers.
If this were a shopping cart for a web site, I can see where they would
like it in session because then it is cleared when the session teminates
and they don't have all this unneeded information in their db. For us
the situation is different and we really need that information to make
sure all information needed for a final transaction is captured. This
is even more important when our pricing might change the next minute
because a storekeeper is adding new stock received and price averaging
is occuring.
Hope this clarifies how we look at things. By the way, I work for a
university and these storerooms are supplying student labs and
researchers and we have some really strict stock control issues with
chemicals and such.
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
