On 1/24/06, Werner Punz <[EMAIL PROTECTED]> wrote: > As for the checkpoint, I cannot say it exactly (maybe matthias can jump > in) it probably will behave like every other page hitting the back > button with no history, that is my closest assumption on what will happen.
And how exactly that would be? (This is a real question not a sarcasm). > If you do not want the history, simply turn it off, it is parametrized > anyway ;-) Why would I want to turn it off? Why this particular choice of page/app synchronization was made? > The whole back restory history stuff has been enabled shortly after > 1.1.1 so it is in the trunk currently. > (And works amazingly well, I must say) I want to believe you, but I would like to hear more elaborate answers to my questions :-) I have a lot of them, I would appreciate answers or links to them if they are in the FAQ somewhere. Michael. > Michael Jouravlev schrieb: > > 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]
