I was more thinking of something like: - store the complex object in the session and remove it when it becomes useless!
Now the question comes: when does the object come useless? It is useless when users gets to step 5 and also when from a middle step (like 3) decides to get out of the this 5 step request-chain. In both cases, the object should be removed from session. I would say to have a configuration file that says for which url-patterns request should the object be kept in the session. So, when another request (which is not part of the url-patterns) comes in, the filter will remove the object from session! What do you think? What else I could do to make sure the session does not become too big? Encode64 sounded like a good idea. Emilia -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: vrijdag 9 juni 2006 14:24 To: user@struts.apache.org Subject: RE: best way to send parameters through more requests Frequent deleting from session is not very good In a cluster that would mean updating the states of session on so many servers on the cluster....you can appreciate that this is an overhead and a great performance hit Request, hidden fields and java script for validation is the work around Also if you decide to use session (you can make the field not required of the stored objects as transient which will improve the performance) Session is good for objects stored (which are not complex and not updated very often) Cheers -----Original Message----- From: Thomas Joseph [mailto:[EMAIL PROTECTED] Sent: 09 June 2006 13:27 To: Struts Users Mailing List Subject: Re: best way to send parameters through more requests One way can be to use the values in session and somehow explicitly delete these attributes after they have been used. Event listeners can I think help here. Just pump an event when you are done with. This should delete the session attributes. Any good patterns in this regard?? References? > Using hidden fields is good, but what if you have like 4-5 request > steps? You will end up at step 5 to send to server a long list of > hidden fileds (all the fields used in step 1,2,3 and 4)... And this > sounds like unmaintable code!!! Thomas Joseph --------------------------------------------------------------------- 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]
