My application has an Asset search form. The user can enter many criteria to search on.
Most of these criteria themselves are looked up from the database (e.g the Person associated with the Asset search). When the user selects a search criteria (e.g. the Person) I store the DTO for that person on my search form. The view element displays details about that Person on the search form until the search form is cleared. Many requests will be made to find the criteria before the Asset search itself is performed. To do this using a request scope form would require that I transfer all of the details I want to display about that person in hidden inputs on the form. If the details I want to display about a Person change then I'd also need to change the hidden fields. In addition once I ship the application to my customers they may have their own JSP developer show extra prpoerties of the selected Person. So, that's my justification for using session scoped form beans. Any comments gratefully recieved. Paul > -----Original Message----- > From: Mark Lowe [mailto:[EMAIL PROTECTED] > Sent: 25 February 2004 11:36 > To: Struts Users Mailing List > Subject: Re: need help converting from session to request scope > > > I have to say I'm changing sides in this debate. The only > 'need' i see > to store forms in the session is for wizard type interfaces, although > I'm looking into a tidy solution into this. > > I agree that hardware it cheaper than time, and that sessions > are by no > means evil, but unless there's a wizard type situation where you want > to span across a number of forms there's no more work > involved scoping > to request. > > > > On 25 Feb 2004, at 12:23, Paul McCulloch wrote: > > > You don't neccessarily have to worry that much about > storing things in > > session. Once the session is terminated (either through > logout, or via > > the > > timeout of your container) the garbage collector will do > that for you. > > > > In my application all form beans are session scope. My > users only use > > one > > form at a time, so when they start using a new form I read > through the > > session and get rid of any other 'old' form beans. > > > > There was a long discussion last week (or the week before) > regarding > > whether > > or not to use session scope. My feeling is that it makes life a lot > > easier, > > so use it unless there is a compelling reason not to - > memory is pretty > > cheap, my time isn't. In my case my application tends to run out of > > CPU well > > before I run out of memory (dual processor box with 2Gb of RAM). > > > > Paul > > > >> In response to Paul: I would like to start storing things in > >> the request so > >> that I don't have to worry about cleaning up all the many > objects I'm > >> putting in the session. I was doing some reading this > >> morning that implied > > > > > > ************************************** > > Axios Email Confidentiality Footer > > Privileged/Confidential Information may be contained in > this message. > > If you are not the addressee indicated in this message (or > responsible > > for delivery of the message to such person), you may not copy or > > deliver this message to anyone. In such case, you should > destroy this > > message, and notify us immediately. If you or your employer > does not > > consent to Internet email messages of this kind, please advise us > > immediately. Opinions, conclusions and other information > expressed in > > this message are not given or endorsed by my Company or employer > > unless otherwise indicated by an authorised representative > independent > > of this message. > > WARNING: > > While Axios Systems Ltd takes steps to prevent computer > viruses from > > being transmitted via electronic mail attachments we cannot > guarantee > > that attachments do not contain computer virus code. You are > > therefore strongly advised to undertake anti virus checks prior to > > accessing the attachment to this electronic mail. Axios > Systems Ltd > > grants no warranties regarding performance use or quality of any > > attachment and undertakes no liability for loss or damage howsoever > > caused. > > > > > > > --------------------------------------------------------------------- > > 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]
