The problem is, that it is hard to ensure having a stopConversation for each startConversation, and what about reloading the page wherepossibly the startConversation gets called twice.
Well, if I'm not completely mistaken, you also have to invalidate all Orchestra conversations manually by now. Could you explain this problem a little bit more? I don't see the point, why forcing the user to stop the conversation manually is a problem.
Reloading the page, however, doesn't matter. Well, of course, it creates another conversation but sooner a later a timeout will invalidate the one that has been created first. I think that's just a matter of implementation and shouldn't affect the design decisions.
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.
The NavigationHandler was just supposed to be an example. However, somewhere, of course, you have to implement that logic, i.e. some callback method is needed in order to handle the "conversation selection", for example, you could use a ViewController for GET Requests.
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 betweenconversations.
Of course, it's best practice not to pass any entities between Orchestra conversations, but that's just true because each Orchestra conversation has got its own persistence context. Seperating conversations and persistence contexts allows you to use the conversation scope in a more fine-grained way (for example, I'd like to reset filter criteria of a search conversation without closing the persistence context).
You could count it as "example 3" of things I don't like in Orchestra. I have to use a single persistence context for a certain dialog (I'm calling it dialog now so that you don't mix it up with Orchestra conversations). Now I'd like to split this dialog into seperate conversations, but I can't because I have to reuse the persistence context so I'm actually reseting some values manually. :-f
However, actually I wanted to talk about my search-use-case as I think that's no problem. Even with a single conversation model it's still possible to create nested conversations (which would meet all requirements for this use-case). In doing so, you've got the advantag that you know which conversation has been calling you, for example in order to reuse the persistence context of the calling conversation.
For example, in this case I'd prefer to write a NavigationHandler for mySee my concerns about get request.
Probably there are even further more examples where a NavigationHandler won't work, but that actually really doesn't matter, because using an API the user has got the possibility to adapt Orchestra to his/her needs. (Btw. implementing another scope that fulfills ones requirements is somehow "extending Orchestra" and not really "using Orchestra" ..).
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.
I think you've answered that already on your own. If "hacking around" is needed for something "trivial" like that, something has to be done, at least in my opinion.
I think in Orchestra everything is there to help you developing your ideas without rewriting the core of Orchestra.
Well, basically you've told me to implement my own conversation scope and my own approach to persistence context handling, if I really feel the need for something like that. But what remains of "the core of Orchestra"? - the ConversationContext.
Please don't get me wrong, but implementing such a scope is just the wrong thing to do. You've already mentioned that it will work as long as I create proxies for my beans to bind the persistence context. Well, I don't need such proxies if I could use a ConversationListener. Assuming that I'm not referencing a conversation-scoped bean as dependency I don't need a proxy at all (of course only in some certain cases, i.e. when I'm not using Spring AOP features). That's just one reason why I think that implementing such a scope is just not right.
regards, Bernhard Huemer On 10/27/2008 +0100, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
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 mySee 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
