When a postback occurs, the ViewState is restored from the previous
request-- in the case of:
Client:
The ViewState is serialized and posted back to the server-- so you could
render a page, come back 5 hours later and click a button, sending the
state you have stored in the page back to the server for use.
Server:
The ViewState is stored on the server, so the page only has a sequence
number to identify, on postback, which rendered state we should use.
lightbulb432 wrote:
That's a good point. Few follow ups below:
1) Could you please explain what, on a high level, the general algorithm
used by the server would be to see whether the state is part of the same
"sequence" of activities? e.g. if I open up two windows and am doing two
different things at the same time, couldn't potentially the jsf_sequences in
the first window be 1,3,5,7,9... and for the second window be 2,4,6,8,10...?
There is no continuity with ViewState-- nor is there an expectation on
the 'sequence' of identifiers, it could be any unique number.
Theoretically, you could store ViewState globally in the application
scope, handing out identifiers from one, shared sequence number.
So I think there's some confusion with the term 'sequence' here, since
it should just be 'unique id' or 'primary key'
How would the server generally tell which came from which window using
jsf_sequence?
Because each window would postback the id rendered in that page, telling
the server which ViewState to associate to process update/action logic.
2) A somewhat related question I have is what is the difference between the
back button problem for client-side and server-side state saving? From what
I've read in articles/posts/books, I get the impression that it's a bigger
problem with server-side than client-side state saving (e.g. even your post
singled out server-side). I know that the state is stored in the actual page
as a hidden field with client-side, but I can't conceptualize how that
solves the problem...after all, if you hit the back button, aren't you
looking at an outdated component tree even with client-side, because that's
what the hidden field has stored?
When you use client-side state saving, you, the client, are always
passing in the page state you are currently viewing, there's no
opportunity to become disjoint from the server state because it's all on
the client.
Original implementations of server-side state did not have any
uid/sequence associated, so as you hit the back and forward button,
there was opportunity for disconnect on what version of 'main.faces' you
were actually working with. Since server-side state now pases a
uid/sequence on postback, there's no question as to which version of
'main.faces' you were currently viewing.
3) You mentioned that jsf_sequence is used with server-side state saving,
but I've noticed it in client-side state-saving's generated HTML as well.
Could you perhaps describe how it would be used with client-side? (Same
reason as for server-side? I'm basically wondering why you singled out
server-side...maybe it'll have something to do with the response to my
question #2...)
jsf_sequence may be used or rendered for other reasons, but i don't
think it's necessary to supplement client-side statesaving since the
rendered Base64 string *is* the viewstate and not just some identifier.
-- Jacob
Thanks a lot.
Jacob Hookom wrote:
If it's like the RI, the reasoning is to accommodate the back button issue
with server-side state saving. It would be wrong to assume/associate a
single state with a page given multiple windows and back button use.
Using a sequence adds a level of uniqueness to state which is equal to
'page + sequence id'.
I've been noticing in my output a jsf_sequence hidden form field that
increments on what seems to be each request. What's the reason for such an
incrementing hidden field?
Does it have something to do with this "back button issue"? If so, how?
I tried using a debugger but quickly got overwhelmed... :(
--
View this message in context:
http://www.nabble.com/Reason-behind-jsf_sequence--tf2860440.html#a7992103
Sent from the My Faces - Dev mailing list archive at Nabble.com.
