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.
> 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.
I thought Bernhard is searching a way how to do solve this problem, and
Orchestra Flow clearly shows how to solve the search-flow-use-case without
having to build your own parameter passing framework.
For me it was clear that passing entities between conversations is a no-go; as
with any framework which allows multiple persistence context.
> >> 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
> > 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..
In your main bean you can have this switch/case to create the bean and put it
into a specific conversation, your main bean then provides a method like
getImplementation.
In your view then you write #{mainBean.implementation.xyz}.
> 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?
>From discussions in the past with Bernhard I got the feeling that he don't
>like the "multiple-conversations per request" approach. Which forced us to
>create something like the view-controller scope, however, I still see no way
>around that. Having the "request" conversation defined by the view controller
>is the best we can do I think.
Ciao,
Mario
