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
