Hi! > So, for example, while in the "Relationships" tab, I may want > to quickly view or edit a Party. The view/edit Party view is usually in the > Party tab. So, essentially I'm reusing the same page in a completely > different flow. > > Now, in reality, I may end up using two different Facelet views that include > the same composition, so this may not be an issue, but you get the idea... > The question for me is if the Relationship and the Party stuff are being processed in the same conversation. If they are not - and I'd think to - then I'd do it that way:
conversationRel navigtes to conversationParty by passing just the primary key of the party to this tab. The party bean then will load the party using its own persistence context. Both conversation should be "manual" conversations. The pro I see, if doing so, is, that if the user switch to the party tab later on - using the normal "tab-navigation" - the previously selected party is still there. Sort of "smart" application, no? Having a button "start-over" which will invalidate the conversationParty and bring up a fresh empty party-edit screen will then easily allow to do different things. I admit, I don't like it to think in page-flows in an webapp. Due to the webapp-navigation possibilities I often do not see it as a single flow, but more a "graph of flows" (better description?), Orchestras named conversations honor that fact not that bad I think. I often use two conversations per page. One manual-non-persistent conversation to hold the data to recreate the state and one access-persistent conversation to deal with persistence. The view-controller backing bean is then the access scoped object and gets the manual scoped "state" object injected. If the users clicks here and there and then back (not browser back ;-) ) to the page it looks as if the application is still aware about what the user wanted to do. But for sure, this will not fit everyones need, just my 2€ct. Ciao, Mario
