Hi Guys, I think the issue over here is, in such cases we need a new scope(workflow scope).The existing scopes(request/session) do not suffice in such cases.
The session scope can be used but it may not be cleared.So there has to be a solution at architecture level.And the struts workflow extension http://www.livinglogic.de/Struts/introduction.html solves the issue.You can define all those aactions as part of a workflow.So any thing u put in workflow scope will be available for the duration of workflow and it will be cleared automaticaly as soon as user leaves the workflow. I had eleborated this problem in one of my earlier mails to this list. http://marc.theaimsgroup.com/?l=struts-user&m=107487218027622&w=2 And I am in the process of moving this project to SourceForge and also add some enhancements.I think if you can have a look at this extension, it should solve your problem. regards, Shirish -----Original Message----- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Thursday, February 12, 2004 10:03 AM To: Struts Users Mailing List Subject: Re: [OT] - Request against Session An alternative is to have an action form then has a number of nested forms or maps in there for example an order. An order contains and addressForm, login/register form, and a payment card form. These are all hand reusable bit n pieces that can be reused. if you nest this in an orderForm, scope the order form to session you can copy the properties from the component forms to the order form. No dirty php hidden form value hacks, and that sort of jazz. AddressForm address = (AddressForm) form; OrderForm order = (OrderForm) session.getAttribute("order"); order.setAddress(address); when the user reaches the end of the order process just. session.setAttribute("order",null); This way you can still rearrange things if/when required but also use the connivence of storing persistent stuff in session, (which I reiterate yet again is what sessions are for). On 11 Feb 2004, at 23:13, Robert Nocera wrote: > Using the session is certainly a possibility, I for the most part, > take the > opposite approach. Generally the only objects I store in the session > are > objects that are going to be accessed throughout the entirety of the > user's > access to the site, stuff like authentication information and role > information. > > I usually will use hidden form fields to carry information from one > page to > the next, but it's usually a small amount of information such as the > keys > for objects that may be needed for a next page. > > I also find that if the entire application is architected so that all > the > information an action needs is in the request as parameters, it becomes > truly simplistic to rearrange the workflow or add links to existing > pages in > places you might not have expected them originally because the call > requires > nothing more than the correct request parameters. > > -Rob > > > -----Original Message----- > From: Mark Lowe [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 11, 2004 4:45 PM > To: Struts Users Mailing List > Subject: Re: [OT] - Request against Session > > There was an interesting posting the other day on this, I tend to stick > stuff in the session because I cant be arsed messing around. After > things are working I then see whether i can move things out. There > seems to be a lot on not storing stuff in the session i imagine because > things can get kinda heavy but then this begs the question what are > sessions for? > > I think people become a bit paranoid about sessions because java is > kinda heavy in this respect, and garbage collection has remained an > issue since its beginnings. But IMO thats for the folks you build the > JVM's to worry about. > > If you want something to persist beyond the request then I suggest put > it in the session. By the time you've messed around trying to avoid > this you could have brought more hardware to deal with the problem. > > I'd say same as wendy, although look back if anything breaks. > > IMO storing values as hidden form values is ugly, I'd use it as a hack > if using session breaks anything (which is doubtful) just set stuff to > null when you're finished and hope the garbage collector comes along. > > > > On 11 Feb 2004, at 22:01, Pani R wrote: > >> Thanks for the advice Wendy. >> >> I may end up storing all the values in the Session. But, on the other >> side, how would I store it in the hidden form variable. I think if I >> store it in my hidden variable, then its available to me in the action >> class via getParameter() which will return me a String object against >> my User Defined Object. Is there any other way to do that? >> >> Pani >> >> -- >> >> --------- Original Message --------- >> >> DATE: Wed, 11 Feb 2004 13:27:11 >> From: Wendy Smoak <[EMAIL PROTECTED]> >> To: Struts Users Mailing List <[EMAIL PROTECTED]> >> Cc: >> >>>> From: Pani R [mailto:[EMAIL PROTECTED] >>>> Now, when the un-logged user tries to register, where am I >>>> suppose to store the Registration Values, Session or Request? >>>> Which one will be the better approach and why? >>> >>> I'm not entirely sure when the session officially gets created, I >>> just >>> expect it to be there, and it always is. If you're going to need >>> something across requests, you can either jump through hoops and put >>> it >>> in hidden form elements, etc., or just stuff it in the session. >>> >>> I tend to treate memory and disk space as infinite resources, which >>> may >>> not scale, but works for my purposes. My vote is to put your values >>> in >>> the session and don't look back. Others may disagree... >>> >>> -- >>> Wendy Smoak >>> Application Systems Analyst, Sr. >>> ASU IA Information Resources Management >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >> ____________________________________________________________ >> Find what you are looking for with the Lycos Yellow Pages >> http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/ >> default.asp?SRC=lycos10 >> >> --------------------------------------------------------------------- >> 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
