<snip> And then he has no more worries as to getting a bloated session, as the session gets trimmed of workflow objects as soon as user goes to any screen which is not part of work flow. </snip>
Unless of course the user simply closes the window. :-( If the user has multiple windows open all sharing a session and does different things in different windows things get really fun. Im not sure if the livinglogic workflow extension has anything to handle this as I havent used it, but I have some familiarity with some of the issues involved. But in my app I had to essentially manage mini-sessions within sessions (I call them Operation Contexts) and that involved using url rewriting to pass around the id of the OperationContexts so that Actions could identify which OperationContext a request was associated with. (The OperationContexts themselves being essentially an object with Map and some other info. (Or in fact a stack of Maps (to support some other requirements such as nav stacks), but thats starting to get off topic...)) I had overridden the RequestProcessor to allow ActionForms to be scoped to OperationContexts as well which was quite useful. Due to the nature of many of the forms in the app (things like any number of file uploads to a single field and slow access to persistence, and tab paney type stuff that had to work in Netscrap6) we really needed to use session scoped forms, but we also needed to support multiple windows open on html forms for different instances of the same record type (and thus same action and form mapping). Doing this in a frameworky way allows managing this to be abstracted away and so the code in the Actions (& form) can concentrate on the task at hand rather than on session management. As for the session management for this ... what a nightmare (bucket loads of javascript, popups submitting to the server to let it know a window closed, some filters, vast amounts of url rewriting). There are so many edge cases... (and its not actually possible to catch them all) - nasty stuff. If you can find a framework to manage this chaos for you then use it! Its not something you want to do yourself unless you really have to... btw: Ive posted about this Operation Context stuff before a few times so you can search the archive if you want more info. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, 12 February 2004 21:49 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [OT] - Request against Session The whole point is there is no concept of a Workflow scope in Servlet API and if you want to share objects , you have to put them in session.And then clearing them is not always easy, as you will never be clear when user may leave the workflow scope.And you have to code for it in every action. What this extension does is to leave all those details to framwrork, and the programmer just has to COnfigure the actions ,saying that they belong to a workflow.And then he has no more worries as to getting a bloated session, as the session gets trimmed of workflow objects as soon as user goes to any screen which is not part of work flow. HTH. regards, Shirish -----Original Message----- From: Robert Nocera [mailto:[EMAIL PROTECTED] Sent: Thursday, February 12, 2004 2:36 PM To: 'Struts Users Mailing List' Subject: RE: [OT] - Request against Session This is probably even more off topic, but I've seen this mentioned before. >From what I can tell of their description of this "workflow" scope, it looks like it may be helpful as far as ease of use goes, but it doesn't offer any real technical benefit over the use of hidden form fields or sessions, in fact, the underlying implementation has to be something passing parameters of using the session, there just isn't any alternative in any compliant application servers. As far as the objects being cleared when the user leaves the workflow, how is that any different the using the session correctly? If the user goes on to another page that is not part of your current "workflow" you can clear those objects or you wait until the user's session times out -- those are really the only two options. -Rob -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, February 12, 2004 4:21 AM To: [EMAIL PROTECTED] Subject: RE: [OT] - Request against Session Hi Guys, I think the issue over here is, in such cases we need a new scope(workflow scope).The existing scopes(request/session) do not suffice in such cases. ... The session scope can be used but it may not be cleared.So there has to be a solution at architecture level.And the struts workflow extension http://www.livinglogic.de/Struts/introduction.html ... --------------------------------------------------------------------- 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]
