I want to go back to your master-detail editing example, Jacob. There is still one important question left. You gave a good description that you use nested conversations to "simulate" a kind of continuation approach. And to create "snapshots" that represent continuable state, you are using a clever mechanism to clone Entities and merge them again with a persistence context. So far, so good.
But in your first post you also mentioned that you're continuing the nested conversations until the end of the application transaction. My question: When the user finally clicks the submit button and your action method persists the state that has been accumulated by the long-running conversation, how do you end all nested conversations up to including the root conversation? The problem ist that an @End annotation does only end the current conversation. And if the current conversation is a nested conversation, it is popped from the conversation stack and then parent conversation resumes again. The same applies to the "end-conversation" element used in pages.xml config file. When you end the innermost nested conversation, do you simply use the timeout mechanism to destroy all enclosing conversations up to including the root conversation? Or do you use some tricks such as calling the Seam Conversation manager to explicitly end all conversations on the conversation stack? (I don't know if that would easily be possible, given that some methods of the Conversation Manager we probably would have to call aren't public but instead private methods.) In July I already wrote on this forum that it would be nice if there was a way to end all conversations on the conversation stack (some sort of "transitive" end), but unfortunately there was any interest. See last post of the following thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112414&postdays=0&postorder=asc&start=10 "jacob.orshalick" wrote : | The main issue that comes in with conversations is the master-details editing where the master controls the persistence of the data. For example, a Person and their Addresses: | | 1. Select Person for editing which displays a Person edit screen | 2. Select Add Addresses which forwards to a secondary screen | 3. Addresses are added and the screen is submitted which updates the in-memory Person | 4. The Person edit screen is redisplayed with the Addresses added | 5. The user then uses the back button to return to the original Person edit screen and submits which persists Person with new addresses | | If a single long-running conversation was used, you end up submitting addresses that were not intended by the user (at least not what they saw on the browser-cached edit screen) since the Person was updated in the conversation context. If the conversation is nested for the Address details screen, the addition of addresses does not affect the outer conversation. In other words, we have a snapshot of state prior to adding the Addresses. | | We do NOT end this conversation when the Addresses are submitted. Instead we continue the nested conversation on the new Person edit screen. Now, if the user was to back up to the original Person edit screen, the snapshot of conversation state is restored (the outer conversation) unaffected by the user's actions. If the user then submits, the state is persisted consistent with what the user "sees." | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086823#4086823 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086823 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
