On Tue, Apr 1, 2008 at 2:30 PM, [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. > 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 > >
