Phrased differently, I guess this would be the idea of a conversation "home". Or, the idea of more control over conversation resuming...
Perhaps by default Seam could simply use the very first ViewId associated with a conversation as the "home" view ID. Then, a new option in @Begin could be:
or something like it.
Another implementation approach that might serve a slightly different purpose would be a new annotation called @Resume.
Seam would call this method when it was getting ready to resume an explicit conversation. The outcome could be run through the regular JSF navigation handler and the appropriate home view could be determined that way. Returning null means that Seam uses the existing view ID assigned to the conversation. Thus, the application gets to control if the current view is kept or changed, and if any other logic is run before resuming.
But you already have control over what view-ids get set. If you don't specify a page description in pages.xml, the view-id won't be updated. So only specify a description on the first page.
Or, probably safer, don't specify descriptions/view-ids in pages.xml, instead call Conversation.instance().setViewId() and Conversation.instance().setDescription() from the @Begin method.
I need to keep using pages.xml as it's the only way to provide a URL abstraction for action methods. I hope someday it supports even more free-form URL patterns, actually.
It appears to me that when I navigate around within the same conversation, Seam keeps track of the last viewId for that conversation. When I go back to an explicit conversation, it resumes at that last viewId. I'm just suggesting that conversations have a concept of a "home view" so that they can easily get back to where they started.
You can use pages.xml without providing description text for every page!
Seam ONLY updates the view id when we hit a page that has a description in pages.xml.
I removed the description from all entries in pages.xml. Fortunately I wasn't using it for anyting yet. However that has made no change to the discussed behavior. Navigating to different views within the same conversation changes the viewId associated with the conversation.
I'm finding this really, really difficult to believe.
If you can create a simple test case that reproduces this, please submit it to JIRA.