On 6/9/06, Samere, Adam J <[EMAIL PROTECTED]> wrote:
Emilia Ipate wrote:
> 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?
You also may be able to store state in hidden fields in the rendered
markup, or by encoding the raw binary data in a single hidden field.
This goes a bit beyond the scope of this list though.
Using hidden fields incurs the following restrictions:
* All pages must contain HTML FORMs.
* All pages must be executed in strict order, so they are tightly
interconnected in one flow, as well as server actions.
* You cannot use redirection.
* Going back and forth without redirection causes POSTDATA messages.
With either hidden fields or request parameters used to store the state:
* Going back may result in rolling back your cart
* Going forward may result in rolling forward your cart
* It is impossible to navigate directly to a certain URL because in
this state info will be lost
Bottom line: storing stuff like shopping cart in hidden fields sucks.
It makes system very unflexible where "usability" is an unknown term.
Store it on server, whether in the session or in database.
On 6/9/06, Emilia Ipate <[EMAIL PROTECTED]> wrote:
I was more thinking of something like:
- store the complex object in the session and remove it when it becomes
useless!
Right.
Now the question comes: when does the object come useless? It is useless
when users gets to step 5 and also when from a middle step (like 3)
decides to get out of the this 5 step request-chain. In both cases, the
object should be removed from session. I would say to have a
configuration file that says for which url-patterns request should the
object be kept in the session. So, when another request (which is not
part of the url-patterns) comes in, the filter will remove the object
from session!
Nope. Clean the cart when a user bails out or finishes checkout
process. Cleaning should be corresponded to user/cart state, not to
URLs.
On 6/9/06, Emilia Ipate <[EMAIL PROTECTED]> wrote:
So I cannot just hold these objects in session forever
Session expires automatically. You can set a shorter timeout interval
if you need. My bank has 10 minute timeout.
On 6/9/06, Albert L. Sapp <[EMAIL PROTECTED]> wrote:
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.
So, do you keep an open db transaction related to a shopping cart, or
you commit each and every cart event. Then, if a user bails out, you
run a correcting transaction, removing all stuff related to shopping
cart? I like database for it robustness and for time-proven clustering
solutions, but considering these transaction-related issues I would
rather use the session. I guess your case is different. It is not like
"I want to buy this, this and this", it is "I already have taken this,
this and this", so the cart reflects events that a user already did to
the stock, and you must not lose them.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
