On 5/27/05, Rafael Taboada <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
