Bernhard, Just to be clear, what you're saying is that you can't use the same view in more than one conversation at a time?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info > -----Original Message----- > From: Bernhard Huemer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 01, 2008 9:00 AM > To: MyFaces Discussion > Subject: Re: [Orchestra] Explicit conversation starting and nested > conversations > > 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 > > > >
