JBossDeveloper

"matt.drees" wrote:
Hi Jacob,

So you're not using a SMPC. I guess I tend to assume everybody uses them. :-) My bad.

So I understand more, but I'm still missing a few pieces.

"matt.drees" wrote:

"jacob.orshalick" wrote:
...Seam has taken a snapshot of my Person entity in the outer conversation on nesting (which didn't have the new addresses). The original Person instance will be reverted back to should the user back up to the original edit Person screen and submit. Seam retrieves the outer conversation by id on submit and restores the state of my Person object at the time of the snapshot which doesn't include the new addresses.

It seems like you're embellishing Seam's behavior a little bit. It's my understanding that when you begin a nested conversation, Seam doesn't take a snapshot, it just creates a new empty "container", and prevents you from storing new objects in the parent container. While in the nested conversation, new objects are stored in this new container, and lookups look there before looking in the parent container; there's no automatic cloning going on. And if a user backbuttons out of a nested conversation, then there's no "restoring" going on, either; the nested container is simply not there, so new objects get stored in the parent container and lookups look there first.

"matt.drees" wrote:

I'm guessing you must be doing this cloning manually somehow to get the behavior you describe, but you speak as if it's automatic. Could you explain a little more or show some code?

our posts have just overlapped, Jacob. Wasn't aware of your latest follow-up when I clicked the submit button.

and it should always read ManagedEntityIdentityInterceptor,
not ManagedEntityIndentityInterceptor

(was using copy & paste to save some typing and always copied the mistake name with an additional 'n')

"baz" wrote:
Very interesting thread.
i like to give a new usecase (or workflow)
We have a search screen, where the user can search for an object(e.g. an experiment)
When navigation to the show/edit screen ocurs a conversation is started and the object(the experiment) is shown.

Now the user can work with the object(the experiment)

What comes in now is a subworkflow. This workflow uses a nested conversation and could be started on any page. When this subworkflow ends, the nested conversation ends and redirection to the starting page occurs.

(...)

My question is how this kind of workflows can be correctly implemented with seam and conversations? For now, it seems to me that it is nessacary to deliver results from the nested conversation to the outer conversation.

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."

Correction:

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 wasn't any interest.

Thanks, Jacob. Great solution.

I'd like to see that included in Seam. And btw, we need the endRoot attribute for the end-conversation element, too.

Otherwise we cannot really end the entire conversation stack when a nested conversation throws an exception.

// pages.xml

<exception class="javax.persistence.OptimisticLockException">
 <end-conversation endRoot="true"/> // end all conversations up to top-level long-running root conversation (inclusive)
 <redirect view-id="/error.xhtml">
 <message>Another user changed the same data, please try again</message>
 </redirect>
 </exception>