Hi! > Example 1) > I've developed some views for a search dialog that I wanted to use in > at > least two different conversations. Everything worked fine for the first > conversation. The following code listing should give you an idea of the > problem.
Simon developed Orchestra Flow which might solve this problem as it creates an all new conversation context for this flow and thus can reuse the conversation setup. Simon is still working on it to make it work with our latest requirements, but it should work for many use-cases already. I am not sure if there is a detailed documentation already. > Example 2) > In a different part of the same application I've created a view that > should serve for three different usecases. Basically the view doesn't > change for these usecases at all, but the logic of the backing bean > does. My first approach was to determine the specific page bean at > runtime in the action method that navigates to this view. This action > method was supposed to register the specific page bean under a common > name. So somehow it can be said that I wanted to use "polymorphic > beans". You might treat it as "workaround" (which you don't want to hear), but the latest Orchestra provides the method convObject = ConversationUtils.bindToCurrent(object) which allows you to attach all the aspects to any bean you'd like to. Allowing to use that from within the spring configuration is on our todo list. > I don't want to hear anything about > certain workarounds that I could have used in these cases as I think > that these usecases aren't exceptional enough to justify workarounds. It is hard to know what you treat as workaround and what we treat as "by design" ;-) However, the missing flow part is nearly there and already usable. > Summarizing it can be stated that I'd propose you to rewrite > conversation handling for the next major release and I'd be willing to > contribute. Note that I don't want to drop support for these "named > conversations", but I think that this usecase is not the default one > for > conversations. I know from the past that you would like to rewrite this stuff, but I've never seen a proposal what exactly and how. Don't get me wrong, but if you'd like to make the "naming-conversation-way" optional you need another way how to deal with the persistence context. Orchestra IS different to Seam here and probably different to Webflow. If the naming-conversations are exceptional ... I don't know, we use it heavily, and now with Orchestra Flow the last missing bit has been developed and Orchestra fits VERY nicely within our application. Probably how we built our application is exceptional (for the good and the bad ;-) ) Well, now with Orchestra Flow it might be possible to reach what you want. If I understood that right. You'd like to have a single conversation active for the request instead for a bean. So, creating a SingleConversationScope, this scope then should hold the persistence context in the conversationContext and bind/unbind it on request start/end. Different conversations then are only possible by utilizing Orchestra Flow. How parallel running conversations should work in such a setup, I don't know yet ... Ciao, Mario
