AW: [Orchestra] Drawbacks of Orchestra I'd like to discuss
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
Re: AW: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Mario Ivankovits schrieb: 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. Documentation is partially there, on the website and on the wiki. But as the code is changing rapidly the docs are lagging somewhat behind. However I think it likely that that things will stabilise into their final form during this week. However (as noted in my other email) flow won't solve this issue. In fact it sets up even more strict isolation between caller and called views - deliberately. The called view cannot access any conversation-scoped data except its own - and whatever parameters it gets explicitly passed. Of course it is possible to pass as a parameter a helper object that *can* access conversation-scope elsewhere. But that is also possible to do without using orchestra-flow. 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'm not sure how the new Conversationutils.bindToCurrent would help here.. It is very useful when a conversation-scoped backing bean wants to pass one of its member objects to some other object. But I don't see how it applies to this caller/callee situation. 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 ... The SingleConversationScope class was recently deleted from Orchestra - as discussed on the list. Partly because there did not seem to be any use-case that it was useful for. We can resurrect it if such a use-case is found. But I don't understand the above description...how exactly does it solve the two issues that Bernhard had? Regards, Simon
