On Tue, Apr 1, 2008 at 3:00 PM, Bernhard Huemer <[EMAIL PROTECTED]> wrote: > 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.
Exactly!! it is what I'm trying to avoid. Maybe this could be achieve with implicit conversation names (not declaring a conversation name to a bean) and the use of the separateConversationContext tag? > > 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 > > > > > >
