On Tue, Apr 1, 2008 at 3:06 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > > 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. > > > I see the use case of allowing to share the page-flow between different > conversations. And probably something like this will come in Orchestra too. > Though, exactly the use-case of "select/search customer" I'd solve in a > different way. > > Why not have - lets say conversationA which then call the search > customer page somehow which uses conversationSearch - at the end of > conversationSearch you'll invalidate this conversation and pass back the > primary key of the selected customer to conversationA. > That way the conversationSearch data can be cleaned up as soon as the > search has been finished. No need to clutter the persistence-context of > conversationA with lots of entities fetched by conversationSearch. >
Yes, good idea, this is a way to implement nested conversation contexts. But this will only work because conversationA and conversationSearch don't share any bean definitions. To achieve the most general case, I think we need to have explicit conversation starting, combining with implicit conversation names, which allow to access the same bean definition using the same name but from two different conversation contexts. Use of tag separateConversationContext allows to start a new conversation but it isn't really a nested conversation context, since it has to be done in a new browser window (no context stack). Am I right? regards > Ciao, > Mario > >
