Hello,
although Orchestra is not about pages, it's most likely that the user
moves through two different page flows if he has started two different
conversations (I'm not talking about two different instances of the same
conversation but rather about two different definitions for a
conversation!). However, there are certain cases where one page flow
overlaps another one but Orchestra doesn't support reusing these pages
as they would use a different conversation.
The problem is that while it's true that you can use different instances
of the same class in different conversations, it's not that easy as each
instance has to have a different name (as you want it to be in a
different conversation). Changing the name, however, "forces" you to
copy the pages using this bean in order to adjust the ValueExpressions.
Maybe I've got something wrong though ..
Regards,
Bernhard
On 04/01/2008 +0200,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
a clem schrieb:
Thank's a lot for your response. What I would like to do is to be able
to share a page (ant its backing bean) between 2 conversations types,
like an activity définition can be shared between 2 process definition
in BPM. For exemple, the select customer page can be shared between
the 'send mail' and 'send invoice' use cases. I think I'm going to
hack the source to see how I can achieve this.
Regards,
On Mon, Mar 31, 2008 at 11:18 PM, simon <[EMAIL PROTECTED]> wrote:
Hi,
On Mon, 2008-03-31 at 22:36 +0200, a clem wrote:
> Hi,
>
> I'm currently playing with this great framework Orchestra, trying to
> build some small examples and a few questions came to my mind:
> Is it possible to start a new conversation explicitly
> (programitically). I've looked to the API but there doesn't seem to be
> something like a begin or start method in it?
Well, there are two answers to this :-)
(1)
If you configure a bean A in Spring to inject some other bean B that is
configured in a conversation scope, then what is actually injected is a
proxy. The bean B isn't actually created, and the conversation is not
created to hold it (though the conversation might already exist if there
are multiple beans in the same conversation).
Then if A invokes any method on B, that triggers the creation of an
actual instance of B plus the conversation to hold it (if the
conversation does not yet exist).
So I guess you could call that "programmatic" creation of a
conversation; whether B is in the conversation or not is controlled by
what A does.
(2)
But if you mean actually creating a Conversation object then placing
objects in it, then no I don't think that is currently possible (or at
least not easy).
In theory there is no reason why Orchestra couldn't support that, I just
think we didn't consider it useful. If there is a good use case then I'm
sure that could be added.
The principle is simple: create a Conversation object then get a
reference to the current ConversationContext and add it. But the problem
is that there are a bunch of settings that a conversation can have which
are defined by a ConversationFactory (which is a mandatory parameter to
the Conversation constructor at the moment). This factory is really
expected to be a Spring scope manager object or similar; I don't know if
it is possible to look this up nicely, or whether it is actually needed
for manually-created conversations. But the settings would need to be
defined somewhere.
Method ConversationManager.getConversation(name) will return
conversations by name, but returns null if the conversation does not
exist; I don't think there is a way of forcing it to exist.
Note that a bean which is *already* in a conversation can add extra
objects to its own conversation via Conversation.setAttribute.
> Can the same backing bean belong to more that one conversation type?
> In other world can I share a view between multiples conversations? It
> seem's that backing beans can only have one conversation name.
No, a bean is expected to be in only one conversation. I think things
would get quite confusing otherwise. For a start, if persistence is
being used with conversations, then a bean could have two persistence
contexts associated with it simultaneously which would be tricky :-)
A bean in one conversation can quite happily call a bean in another
conversation of course (orchestra conversations are not like WebFlow or
Seam conversations).
What would the use case be for this?
> And
> finally, is it possible to have nested conversation contexts? Thank's
> for all your coming responses! :)
No, but that feature is definitely on the to-do list.
Orchestra does support multiple concurrent named conversations, as I'm
sure you're aware. That solves many of the use-cases for nested
conversations but not all of them.
Good questions - I should put these on the Orchestra wiki FAQ page.
Unless perhaps you would be willing to do that?
Regards,
Simon
You can have two instances of the same bean class in two different
conversations without problems.
But to have the *same* instance in two different conversations still
doesn't make sense to me. Your example of "pages" doesn't clarify this
for me; orchestra is not about "pages", but about beans (some of which
may be backing beans).
Regards, Simon
