When the back button does not work!

Refer to this thread for background and problem analysis.

Make sure you check pages.xml when your back button is not working.

Example:

<page view-id="/ManageEquipment.xhtml">
    	<description>Manage Equipment</description>
    	<navigation from-action="#{manageEquipment.processRepairHistorySelection}">
    		<redirect view-id="/RepairCaseDetails.xhtml"/>    		            
        </navigation>
        
        <navigation from-action="#{manageEquipment.searchSerialNumber}">
        	<redirect view-id="/ManageEquipment.xhtml"/>
        </navigation>
        
    </page>

The second <navigation> block above fixed my problem and now the cid is not being lost. When I click the browser back button, the previous page is displayed with all components/data intact. Previously it was being wiped out after the temporary conversation was destroyed. There was a LRC but b/c the cid was lost, a temporary conversation was instantiated (remember with Seam and HTTP requests, there is always a conversation, but it may be temporary or long-running).

With the above configuration in pages.xml, when user clicks the submit button to execute a search, the cid is post-pended to the URL on postback. Seam will no longer use a temporary conversation and thus the SFSB modeling the LRC will not be destroyed prematurely.

In Seam, if a business method of a Seam component returns void, there will be a postback after successful form submission and method execution. If you return a String, it will forward the request to foo.xhtml.

Summary: if you want to make sure Seam does not lose your conversation id, make sure you use <redirect> for the appropriate action in your pages.xml so that on postback, the URL contains the conversation id and you avoid problems with browser back button scenarios.

As per DAllen from SiA book, pg. 101:

The presence of the <redirect/> element in the rule indicates that a redirect should be issued prior to rendering the next view, rather than rendering the view immediately in the same request, which is the default. A redirect results in a new initial request.

As per KMann from JSFiA book, pg. 132:

The last navigation case specifies the <redirect> element, which tells JSF to send an HTTP redirect to send the user to the new view, as opposed to forwarding the user to the view internally. The <redirect> element also forces the request for the new view to be handled externally by the web container, which means it will be processed by any additional application logic you may have (like a servlet filter).