<snip> How it is implemented is not important. </snip> Well except in that the abstraction cannot be total due to the underlying technology limitations imposed by working with http and browsers over which one has very little control. My example of multiple windows and not knowing when windows are closed illustrates this. Even with a framework in place a developer really needs to be aware of what is going on below his code to support this extra context and sometimes has to add code to supplement this. The session provided by the servlet api has similar difficulties as can be seen with the need for the developer to ensure that they invoke url rewriting on links to cover the case where cookies are disabled.
Limiting to one window (and using tokens and other such techniques to ensure that the user sticks to one window) can simplify matters immensely. (The customers desire for multiple windows often rules out this possibility though. Having to suddenly change to support multiple windows when one had been developing all along with a one window restriction can be especially annoying (been there)) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, 13 February 2004 16:46 To: [EMAIL PROTECTED] Subject: RE: [OT] - Request against Session But what we are talking about is the concept & functionality.And what you are saying is the implementation. Agreed the workflow container is in session scope .But for the user(The developer), it gives the choice of an additional scope definition.How it is implemented is not important. Any how, when we are talking about any such implementation/Concept, we have to implement it in the context of available APIs. -----Original Message----- From: Michael McGrady [mailto:[EMAIL PROTECTED] Sent: Thursday, February 12, 2004 11:53 PM To: Struts Users Mailing List Subject: RE: [OT] - Request against Session At 07:50 AM 2/12/2004, you wrote: >If user has different windows in different windows, then only the latest >windows workflow is honoured.SO all other window will have lost thier >workflow state if any...Which is desired behaviour in workflow like >situations...Where you dont want user to have multiple windows open and >accidently submit an old window with stale data thinking he was working >with the latest data... > >But you are right in the sense that all such stuff should go in framework... This, I think, is a misunderstanding of what happens. There STILL is a workflow container in session scope, and what is MORE, even where you don't need a workflow container, you still have one in session scope. --------------------------------------------------------------------- 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]
