Hi! > Well, basically I'd refactor the ConversationContext so that it's > actually the main conversation of Orchestra. The conversation itself is > almost independent of Spring (of course, there's still an according > implementation of the Scope interface, but it will be implemented way > easier). It's possible to nest conversations, i.e. a there's a certain > hierarchy of conversations.
The main problem I see with this approach is that you HAVE to use a flow definition, else Orchestra has no chance to determine when to end a conversation and when to reuse the current one. In a web-application, where you have global menues where the user is able to "suspend" the current conversation and jump right to the start of another one (or resume it) it is hard to find the conversation demarcation without a flow description. In fact I tried such thing in Orchestra BEFORE I started to go the named-conversation way. Orchestra just fits way better with this "free-floating-named-conversations" in our application. As far as I know Spring WebFlow is such a system and is able to deal with persistence contexts already. > Each conversation has got it's own lifecycle and therefore it's > possible > to register so-called "conversation listeners" in order to hook logic > into such lifecycle phases. Some of the events you outlined are already there in Orchestra. Also using Orchestra without persistence at all works great, on a per-scope-configuration basis! Still, the beauty of Orchestra is that it supports use-cases like: 1) Doing Order-Processing 2) Suspend task 1 and do some different things like, update customers master-data 3) Go back to Order-Processing and continue All this works without a single line of flow-description and by nicely separate the persistence contexts, so the memory of task 2 has been freed while task 1 is stil there. Also no user-interaction is required (pause, restart, etc) and no other sort of convention. On top of THAT we built the flow, so each flow separates even more by still keeping the easy-to-use multiple conversation feature. Where a flow is required (e.g. search-pages) you can use them now. So, it is not only using two conversations during the same render-request, no, it is about using different parallel conversations for different tasks without additional configuration on view level. In fact, if one finds a method how Orchestra can determin what is the CURRENT conversation we could get rid of the viewController-scope, but since Orchestra talks about beans and not about views in its innerst, that is hard to find. For me the single-conversation approach looks like a limitation, which to break out requires a flow-description. Sorry, at all it is hard for me to see what is better to do it like Spring WebFlow. Ciao, Mario
