myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "a clem" <a.p.clem...@gmail.com>
Subject Re: [Orchestra] Explicit conversation starting and nested conversations
Date Tue, 01 Apr 2008 13:09:37 GMT
On Tue, Apr 1, 2008 at 2:30 PM, simon.kitching@chello.at
<simon.kitching@chello.at> 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 <simon.kitching@chello.at> 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.
>
Yes It is what I want to do. How can I do that since beans can only
have on conversation name?

>  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).
>
Yes to me either! ;) I'm talking about pages because pages access
(backing) beans trough their names an having differents conversation
names means having to duplicate the page.

regards


>  Regards, Simon
>
>

Mime
View raw message