Not sure whether my point can be extended to dynaaction forms as i rarely use them. But certainly with plain old action forms it seems to be the case, I haven't looked but Niall's Lazy version will probably address using dynaactionforms with nested properties scoped to request. IMO dynaaction forms increase development time as you cant see problems until runtime, but okay for the odd simple form.


On 25 Feb 2004, at 12:36, Mark Lowe wrote:


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]



Reply via email to