[JSF] history list support (Back/Forward buttons)

[Michael Jouravlev <jm...@gmail.com>]

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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [JSF] history list support (Back/Forward buttons)

[Michael Jouravlev <jm...@gmail.com>]

Ok, I will search myfaces list too. Thanks!

On 1/24/06, Werner Punz <we...@gmx.at> wrote:
> Sorry to answer again, this is a question which probably is asked best
> in the myfaces mailinglist, you might reach the author (Matthias B...)
> there directly.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [JSF] history list support (Back/Forward buttons)

[Werner Punz <we...@gmx.at>]

Sorry to answer again, this is a question which probably is asked best
in the myfaces mailinglist, you might reach the author (Matthias B...) 
there directly.


Werner



Werner Punz schrieb:
> Actually sorry to jump in here, but I was partially wrong in my posting
> in the long tss thread,
> 
> the number of stored states is parametrizable.
> Matthias Broeckelmann who did it for myfaces basically added
> parameters for the saved states and also for the handling of saving it 
> into the session or not.
> 
> 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.
> 
> If you do not want the history, simply turn it off, it is parametrized 
> anyway ;-)
> 
> 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)
> 
> 
> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [JSF] history list support (Back/Forward buttons)

[Werner Punz <we...@gmx.at>]

Michael Jouravlev schrieb:
> On 1/24/06, Werner Punz <we...@gmx.at> 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).
> 
As I said Matthias Broeckelmann proably can answer this best in the 
myfaces list since I am only a user of this thing not the author.
What probably happens is following, you run into the same situation 
which you would run without a restore history.

You would go to a page and run the full restore cycle but not with the 
history, only with values which either are request or session bound and 
merged with the incoming request data.  You are definitely in a 
stateless situation. Since most of the shifts between pages are caused 
by posts you can figure out yourself what would happen in such a case 
;-). Even if you have a restore of the values you definitely would lose
altered component or user interface states.

So you basically probably run into the same issues you would have
to face by pressing back without any history at all.

But that is only an assumption an error condition also could be possible 
(but is very unlikely since JSF itself does not have such a condition 
per default, so it does not make sense to do it, and probably would 
break the TCK)


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [JSF] history list support (Back/Forward buttons)

[Michael Jouravlev <jm...@gmail.com>]

On 1/24/06, Werner Punz <we...@gmx.at> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [JSF] history list support (Back/Forward buttons)

[Werner Punz <we...@gmx.at>]

Actually sorry to jump in here, but I was partially wrong in my posting
in the long tss thread,

the number of stored states is parametrizable.
Matthias Broeckelmann who did it for myfaces basically added
parameters for the saved states and also for the handling of saving it 
into the session or not.

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.

If you do not want the history, simply turn it off, it is parametrized 
anyway ;-)

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)


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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org