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.
>>>>
>
>
>> 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.
>
Agreed. The possible solutions for this kind of "shared search dialog" are:
(a) have the backing bean for the search dialog run in the same
persistence context as the caller (Berhhard's proposal)
(b) have the persistence contexts completely separated, and just pass
*keys* between the caller and called views
(the approach that we currently use at OPS)
(c) have the caller pass a "helper" object to the called view. The
called view's backing bean then runs in its own persistence context, but
methods invoked on the helper can run in the caller's persistence
context (or anything else the caller sets up).
* Option (a) is currently not supported by Orchestra core. We have
considered it before, but I'm not at all sure it is the right approach.
It is convenient in the short term, but IMO leads fairly directly to
hard-to-maintain code. And I'm not sure how it could be implemented either..
* Option (b) works and is reasonable.
* Option (c) hasn't been tried anywhere AFAIK, but also seems reasonable.
Orchestra-flow just builds on orchestra-core, so doesn't support (a)
either. It does make implementing (b) and (c) easier but doesn't change
the orchestra-core fundamental design.
>>>> 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}.
>
I think this is the same as the solution Bernhard described in his
original email, but that he didn't like, ie the
"#{pageAccessor['commonBean']}" approach. IMO this approach is quite
reasonable. I would personally write the EL expression as
#{myview.helper.x} or #{myview.impl.x}. Or just write some delegation
methods on the backing bean, so that myview.x always just passes the
call on to its helper object.
Note that the "helper" instance should be bound to the appropriate
conversation by using ConversationUtils.bindToCurrent(), so that all
methods on it run in the appropriate conversation scope.
There is another ugly solution: rather than trying to put the backing
bean into the conversation as an attribute, instead put it into
session-scope. It will be found there before any attempt to locate a
spring bean occurs. It's not very nice though; the most significant
problem is that the bean needs to be explicitly removed from
session-scope at some time.
>
>
>> 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.
>
Ok, I see. BTW, I'm not a great fan of the "view controller scope",
although I have to admit I don't see a better solution at the moment.
Cheers,
Simon
--
-- Emails in "mixed" posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)
