<snip> To maintain functionality across a standard scope (request, session, application) something in the work flow application will have to go into that scope or into some other equivalent persistence mechanism such as a database. If the work flow application maintains the persistence, then it is merely using the regular scopes. And, it does not provide any new scope. </snip>
Yes, the WorkflowScope can never be any more than a way of abstracting some of the tiresome details of managing such session scoped stuff across requests. The code that makes use of the so-called WOrkflowScope can treat it conceptually as a new scope that has many characteristics in common with the session, but underneath it really is just a part of the session or maybe stuff put in a db. That 'stuff' will obviously use storage space (RAM or DB), and knowing when it is ok to discard it is the tricky bit (whether your implementing a workflow framework or doing a one off thing for a particular use case). The worst case scenario is that everything added remains until the session is expired. The best scenario is that everything is removed as soon as it is no longer needed. Depending on the nature of the app, the reality is likely to be somewhere between the two as there are some cases of abandoning a workflow that simply cannot be reliably detected (ie: window closure). -----Original Message----- From: Michael McGrady [mailto:[EMAIL PROTECTED] Sent: Friday, 13 February 2004 16:57 To: Struts Users Mailing List Subject: RE: [OT] - Request against Session At 12:45 AM 2/13/2004, you wrote: >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. I too am talking about the concept and not an implementation. Nothing in what I said is implementation specific. There simply is no such thing as "work flow scope". That is fiction. Whatever is retained in the work flow environment is retained in regular old scopes: request, session, application. The talk of "workflow scope" sounds good and fancy, but it means nothing. To maintain functionality across a standard scope (request, session, application) something in the work flow application will have to go into that scope or into some other equivalent persistence mechanism such as a database. If the work flow application maintains the persistence, then it is merely using the regular scopes. And, it does not provide any new scope. That is not a correct description of what is going on. That is all I am saying. Anyway, I am saying nothing that is implementation specific. That reading of my point is just wrong. --------------------------------------------------------------------- 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]
