Hi! > > 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. > > Well, no, you don't have to use a flow definition. Managing the > conversation from a user's perspective is clearly defined as an > according API will be provided. If the user doesn't call a method like > "conversation.invalidate()" the conversation won't end. > > For example, I'm thinking of creating a configurable artifact that > manages the lifecycle of a conversation - a so-called > "ConversationManager". The basic implementation would require the user > to call the method "manager.startConversation()"
The problem is, that it is hard to ensure having a stopConversation for each startConversation, and what about reloading the page where possibly the startConversation gets called twice. Another problem ist that not each and every page-flow is triggered by a navigation-handler event, what about get requests - e.g. from the main menu. Also, what about your search-use-case? If you navigate from the page to the search dialog and came back, you (or, at least I) want to throw away the persistence junk collected through the search-flow. Having just one conversation means you keep tons of entities (and possibly stale data). In contrast, using startConversation from within the search leads you to the same problems (and even more) than you have with Orchestra which forbid you (or, at least it is not best practice) to pass entities between conversations. > Well, I'm not particularly against named conversations. I'm just saying > that neither the view nor a Spring bean is responsible for determining > the name of this conversation, but a special "flow logic" is (and I'm > still not talking about flow definitions). Ok, so start with a scope implementation which overrides getConversationName() (or something like that). Couldn't you just plug the logic in there? The point is, once the bean has been instatiated the persistence context is not allowed to change. What if the bean holds entites as strong reference, if the persistence context changed these objects gets detached (or simply reuse an already closed persistence session) > For example, in this case I'd prefer to write a NavigationHandler for > my See my concerns about get request. > application that knows how to deal with this usecase. Basically it uses > the according API to suspend the current conversation and resume the > according one. Of course, Orchestra could only do that automatically if > there was something like a flow definition, but I'd prefer to expose an > API so that the user is able to write such a NavigationHandler on his > own. Orchestras API should be open enough to implement any sort of system as long as you proxy your beans to setup the persistence context. You might be able to even hack around that as you could grab the persistence context from the conversation attributes map and bind/unbind it at request start/end as long as you know which conversation to bind to. Probably by using a special named _main conversation. This should allow you to jump start with your idea and see if it really fits your application needs. > > Also no user-interaction is required (pause, restart, etc) and no > > other sort of convention. > > Well, of course you could say that this is a burden for the user, but > it > comes with great flexibility too (see my master-/detail-view example). It is not only a burden for the user, it is impossible to ensure from within your application I think (still). > Simply said, yes that's true, but the flow description doesn't have to > be an XML flow definition. What I'd like to see, is an Orchestra API > that allows me to describe my flows programmatically at runtime as this > is a much more powerful approach for managing conversations. You can create your own flow implementation on top of orchestra and use a special conversation scope implementation which uses the conversation name "_main" as a fixed string. Then, the only thing you have to deal with is the conversationContext. If your custom scope avoids creating the conversation if it doesn't exist you even can try to implement the @Create stuff. I think in Orchestra everything is there to help you developing your ideas without rewriting the core of Orchestra. Ciao, Mario
