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]
