Werner Punz wrote the following on 7/28/2005 11:46 AM:
There are some ways to handle this
a) You can dump anything into the session, which means you run into
memory problems in the long run.
I use this solution and have yet to run into any sort of memory
problems. Resources aren't 'that' expensive. Use the Session unless you
find out you have performance issues.
b) you can put everything into hidden fields, which means you have
myriads of hidden fields, which is slow and error prone to implement.
Maintenance nightmare.
c) You can try to add the stuff manually to the session and remove it
later, which also is problematic in case of an error because then you
have a mem leak caused, by a tangeling object in the session.
Above is talked about a lot on this list, but have yet to see a good
implementation of it. I think it will be a difficult undertaking and
could be a pain to configure. The control mechanism will have to figure
out when and what to clear out of the Session at any given time. Say the
user clicks on some other link.. that path(I'm assuming) will have to be
checked to see if it's safe to remove x number of Session based objects.
I've tossed around with the idea of associating certain 'paths' with a
Session scoped action form and as each request passes through the main
filter it would check the path and based on the path and certain objects
in scope certain ones would be be removed. Seemed like such a pain
though so I gave up before I even really started on it:)
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]