Seems that JSF-related flame on TSS http://www.theserverside.com/news/thread.tss?thread_id=38601 died, and I have left without an anwser ;-) So I am repeating the question here with some modifications in hope to get "i" dotted and "t" crossed.
The question is: how history lists and in particular Back button, is supported in JSF, including: * JSF spec * JSF reference implementation * MyFaces * Shale * Other I searched Net just a bit, and found indications that Back button issues regarding component state are resolved in 1.2 spec: http://weblogs.java.net/blog/edburns/archive/2005/08/javaserver_face_3.html I downloaded spec and glanced across but did not find the answers. Granted, I did not read it thoroughly. If the answers are there just tell me so, if you can point to specific sections that would be great. JSF 1.2 spec does not contain expressions "back button" or "history". The official HTTP term for browser page history is "history list". The spec reads that if request is not a postback, a response should be rendered (using current state, right?). If request is a postback, then viewsate should be restored. Depending on using <redirect/> instruction in config file, both cases are possible when clicking Back button unless renderkit uses some sort of token and detects that the received POST request is actually a resubmit of old data and should not be considered as postback. Anyway, in either case JSF has to [optionally restore viewstate] + render view according to state. The question is, where the state comes from? What are the rules for buffering/queueing/caching state? Werner Punz wrote: "MyFaces is not a project like Tapestry which tries to built its own framework but it tries to stay within the JSF standardization thats basically it." What exactly does JSF spec say about saving/restoring state in case of history list navigation? Werner explained how RI/MyFaces solved history list issue: "The back button issue is solved both in the RI as well as in MyFaces on server side state saving. There is code which restores the last 20 possible states in case of a back to my knowledge." I could not find details of this process neither in section 2.2, Standard Request Processing Lifecycle Phases nor in section 2.5.3 State Management. The latter section seems unfinished. I see the following options for browser/server behavior when Back button is clicked: === crosspost from TSS starts === 1) Click Back, page is cached, or page is non-cached but browser honors history list (Opera, see HTTP 1.1 section 13.13). Stale page is shown, server is not notified ==> server and page are out of sync. 2) Click Back, page is non-cached and browser agrees to reload a page from server (Firefox, MSIE, other). Page is updated according to server state, say by changing "Add" button to "Edit" button for the same data or by displaying a different subview ==> server and page are in sync. 3) Click Back, page is non-cached and browser agrees to reload a page from server. Application recognizes that browser reloads a page corresponding to previous state. Viewstate is rolled back, page is displayed with data corresponding to that state. ==> server and page are in sync. Seems like MyFaces uses approach (3), I prefer approach (2). * What happens in case (3) when a user clicks Forward after clicking Back? Will the viewstate be rolled forward? * How does viewstate correspond to model state in case (3)? What if I use third party to charge a credit card, how do I roll the business transction back? And then roll it forward? * Approach (3) works when page *is* actually reloaded by browser. What if it is not? The browser would show stale page which would be out of sync with server. So, approach (3) works only if page is actually reloaded, as well as approach (2). With both techniques, browser and server go out of sync if page is not reloaded. So, approach (3) still sucks when page is being cached, but requires more efforts when page is reloaded. Is the result worth the labor? Do you really think that a user who just payed for his new digital camera online, expects to see the same "Confirm your order" page again when he hits Back button? I think that he would shit in his pants trying not to click submit button again. I would prefer to see "Your order was processed" and "Show Order Info" button instead. === crosspost from TSS ends === If I understand correctly, JSF uses approach (3) from the list below. Am I right and why it was chosen instead of approach (2)? What happens if I use third party to process a request, say to charge a credit card, and a user clicks "Back"? How can I give hints to state saving mechanism that checkpoint is reached and there is nowhere to rollback? What JSF will do if there is nowhere to rollback: will show stale page with corrupted data or will show different version of the page corresponding to *current* state? If latter, why it cannot be default behavior? By the way, seems that Wicket guys have the same notion of "Back button support" as MyFaces. Michael J. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
