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
