Thanks for the detailed response.
>> 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.
Does the server actually store the ViewState associated with EVERY single
jsf_sequence number? I'd imagine that it'd only store it for what it
deems
to be each separate sequence of tasks (e.g. in a given window), then
overwrite/update that ViewState associated with one window, but keep the
other ViewState around for when that one comes in. That's why I'm
wondering
how the server knows which jsf_sequence number is associated with which
other jsf_sequence number as part of the same window... (I wonder if any
of
what I said was coherent...?)
I'll try to explain my question: You open one window and go to the page
and
get a jsf_sequence of 332 - the server creates a component tree on the
server in reponse and associates it with jsf_sequence 332. You open
another
window and get a jsf_sequence of 154 and similar things occur. In the
first
window you submit a form and get a jsf_sequence of 778. Now does the
server
have 3 component trees in its memory? (One per sequence number?) Or just
2?
(One per window?)
I'd imagine it'd be the latter. But if so, how does it know that the
component tree of 332 should be "overridden" by component tree associated
with 778? Wow, I'm so confused...I'm pretty sure I'm not even thinking
about
this in anywhere near the right way!
>
> 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.
>>>>
>>>>
>>>
>>
>>
>
>
>
--
View this message in context:
http://www.nabble.com/Reason-behind-jsf_sequence--tf2860440.html#a8004461
Sent from the My Faces - Dev mailing list archive at Nabble.com.
