Radu.
To avoid such problems you may use contextes. When you have contextes stored in the session and you store your values only in this context you have no problem to clean the session. There is a small architecture project called struts-it (struts-it.org) in detail http://plstrutsit.sourceforge.net/architecture/presentation.html, provides such a context. The signature of an execute-method is such as
public void execute(Context context);
where a context is a commons-chain context. The Request processor has the responsibility to create such contextes and share them over an use-case. This approuch is available for struts 1.2 as well as struts 1.1.
I think the struts-chain (1.3) has the same approuch. Dealing witch contextes is quite nice, because you can use this context in the business layer too.
Manfred
Radu Badita wrote:
At 08:14 14.03.2005, Craig McClanahan wrote:
For a developer, though, you should train yourself to good habits in the first place -- use request scope for *everything* unless it absolutely must be saved, on the server side, in between requests from the same user.
This sounds like common-sense but is only feasible in theory; that's because in non-trivial web-apps almost all the interactions are some kind of a dialog spanning multiple requests with the user and inevitably require session-stored data between request. Cleaning such data when the "dialog" ends becomes a pain.
I hope that the "Dialog Controller" in the forecoming Shale will address this problem and provide the means for a "dialog-local session" that will automatically be released once the dialog completes. Furthermore, once a user is in the middle of such a pageflow, it shouldn't be possible to leave (requesting another dialog sequence) until the current one finishes.
I've once worked with a home-made web framework which implemented such behavior (like a state machine) where the entire application was divided into states (each having a corresponding view), each state could have transitions (a transition executing an action) to other states or to another sub-application. Each "state machine" had it's own separate session which was removed on execution end. Between state-machines parameters could be sent by-value copying from one session to the other. All this was specified in an external xml doc. Too bad it was lacking a system for automating request and session parameters retrieval (like the ActionForms in Struts).
That is the behavior that I would personally like in Shale, because I think it allows for much better design and reuse.
Radu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
=========================================== Dipl.-Inf. Manfred Wolff Software Engineer ------------------------------------------- http://www.manfred-wolff.de http://www.struts-it.org ------------------------------------------- ____________________________________________________ den.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
