Re: Reason behind jsf_sequence?
lightbulb, It doesn't sound like you are discussing JSF navigation here at all. Key point to note: by default, JSF navigates with server-side forwards. These *do not* result in the browser URL being updated. :) regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. lightbulb432 wrote: Regarding the back button problem, I have a question: So the issue is that you have an original page with a form on it (page1.html) that was obtained through a GET; the browser bar shows page1.html. You POST that form to a destination of page2.html (as defined in form) and a response is generated in whatever way and the browser bar now shows page2.html. First question: is this a postback? (Is a regular POST the same as a postback?) From page2.html, the user hits the back button...doesn't it just do a GET on page1.html and all is fine? What's the issue? I'd guess that hitting the Refresh button would cause another POST to page2.html with the same parameters, but hitting the Back button would cause a GET to page1.html...am I totally off here? 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.
Re: Reason behind jsf_sequence?
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! Jacob Hookom wrote: 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
Re: Reason behind jsf_sequence?
On 12/21/06, lightbulb432 [EMAIL PROTECTED] wrote: 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! The best way to address your confusion would be to look at the actual source code, and see what actually happens for yourself. The source code for both MyFaces and the JSF RI is open source ... you'd answer your questions a lot faster by just taking a look at what actually *does* happen. Craig Jacob Hookom wrote: 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
Re: Reason behind jsf_sequence?
Lightbulb, Take a look at the context-param: context-param description Only applicable if state saving method is server (= default). Defines the amount (default = 20) of the latest views are stored in session. /description param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION/param-name param-value20/param-value /context-param This is a myfaces thing. Basically it will store the last X number of component trees, and when a new sumbit occurs it uses the sequence number to look up the right component tree. It has no idea whether they are coming from the same or different windows. It does not overwrite the old ones until it runs out of room (that's the whole point of the sequence numbers, so you can have several copies of the same view with different component trees). I agree with Craig though, you can learn a lot from the source - much more than just looking naively at the generated output. :) Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Craig McClanahan wrote: On 12/21/06, lightbulb432 [EMAIL PROTECTED] wrote: 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! The best way to address your confusion would be to look at the actual source code, and see what actually happens for yourself. The source code for both MyFaces and the JSF RI is open source ... you'd answer your questions a lot faster by just taking a look at what actually *does* happen. Craig Jacob Hookom wrote: 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
Re: Reason behind jsf_sequence?
Ok, I'll look at the source and see what I come up with. Could somebody please provide guidance as to how to get started (as I've never seriously looked at code for a real program and knew what I was doing...) I saw the wiki page that somebody posted earlier on the different classes and methods to watch out for, so I'll follow that. Do I need the source for anything apart from the 2 MyFaces JARs? (e.g. any supporting libraries that'll inevitably pop up throughout the processing?) Also, from the time I start tracing the call from the entry to Faces Servlet to the actual response being generated and sent back out, how many classes should I expect to come across in the debugger? Are we looking at thousands, or just a few, or what (yah, dumb question, but I don't know in how much detail to follow the stack trace - i.e. do a lot of step intos or step overs - how should I proceed in the actual debugger?) Thanks. Jeff Bischoff wrote: Lightbulb, Take a look at the context-param: context-param description Only applicable if state saving method is server (= default). Defines the amount (default = 20) of the latest views are stored in session. /description param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION/param-name param-value20/param-value /context-param This is a myfaces thing. Basically it will store the last X number of component trees, and when a new sumbit occurs it uses the sequence number to look up the right component tree. It has no idea whether they are coming from the same or different windows. It does not overwrite the old ones until it runs out of room (that's the whole point of the sequence numbers, so you can have several copies of the same view with different component trees). I agree with Craig though, you can learn a lot from the source - much more than just looking naively at the generated output. :) Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Craig McClanahan wrote: On 12/21/06, lightbulb432 [EMAIL PROTECTED] wrote: 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! The best way to address your confusion would be to look at the actual source code, and see what actually happens for yourself. The source code for both MyFaces and the JSF RI is open source ... you'd answer your questions a lot faster by just taking a look at what actually *does* happen. Craig Jacob Hookom wrote: 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
RE: Re: Reason behind jsf_sequence?
I, personally, find reading the specifications to be the easiest route-- check out JSR 252 at the JCP.org site and download the specification PDFs to give you an introductory view into the lifecycle of JSF, then provide the gritty details of how JSF works. http://jcp.org/en/jsr/detail?id=252 -- Jacob Ok, I'll look at the source and see what I come up with. Could somebody please provide guidance as to how to get started (as I've never seriously looked at code for a real program and knew what I was doing...) I saw the wiki page that somebody posted earlier on the different classes and methods to watch out for, so I'll follow that. Do I need the source for anything apart from the 2 MyFaces JARs? (e.g. any supporting libraries that'll inevitably pop up throughout the processing?) Also, from the time I start tracing the call from the entry to Faces Servlet to the actual response being generated and sent back out, how many classes should I expect to come across in the debugger? Are we looking at thousands, or just a few, or what (yah, dumb question, but I don't know in how much detail to follow the stack trace - i.e. do a lot of step intos or step overs - how should I proceed in the actual debugger?) Thanks. Jeff Bischoff wrote: Lightbulb, Take a look at the context-param: context-param description Only applicable if state saving method is server (= default). Defines the amount (default = 20) of the latest views are stored in session. /description param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION/param-name param-value20/param-value /context-param This is a myfaces thing. Basically it will store the last X number of component trees, and when a new sumbit occurs it uses the sequence number to look up the right component tree. It has no idea whether they are coming from the same or different windows. It does not overwrite the old ones until it runs out of room (that's the whole point of the sequence numbers, so you can have several copies of the same view with different component trees). I agree with Craig though, you can learn a lot from the source - much more than just looking naively at the generated output. :) Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Craig McClanahan wrote: On 12/21/06, lightbulb432 [EMAIL PROTECTED] wrote: 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! The best way to address your confusion would be to look at the actual source code, and see what actually happens for yourself. The source code for both MyFaces and the JSF RI is open source ... you'd answer your questions a lot faster by just taking a look at what actually *does* happen. Craig Jacob Hookom wrote: 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
RE: Re: Reason behind jsf_sequence?
Should I be reading version 1.2 or version 1.2 (Revision A)? I figure that there are implementations of 1.2 but not 1.2A so if I read the latter there may be things that haven't been implemented yet in the version of JSF I'm playing with, leading to confusion? Is this correct reasoning, or is that not how revisions of final specs work? (i.e. The only changes are not changes to functionality and major things like that...) Or would a JSF implementation work to become 1.2A compatible after 1.2 then call themselves a 1.2A-compliant spec? Jacob Hookom wrote: I, personally, find reading the specifications to be the easiest route-- check out JSR 252 at the JCP.org site and download the specification PDFs to give you an introductory view into the lifecycle of JSF, then provide the gritty details of how JSF works. http://jcp.org/en/jsr/detail?id=252 -- Jacob Ok, I'll look at the source and see what I come up with. Could somebody please provide guidance as to how to get started (as I've never seriously looked at code for a real program and knew what I was doing...) I saw the wiki page that somebody posted earlier on the different classes and methods to watch out for, so I'll follow that. Do I need the source for anything apart from the 2 MyFaces JARs? (e.g. any supporting libraries that'll inevitably pop up throughout the processing?) Also, from the time I start tracing the call from the entry to Faces Servlet to the actual response being generated and sent back out, how many classes should I expect to come across in the debugger? Are we looking at thousands, or just a few, or what (yah, dumb question, but I don't know in how much detail to follow the stack trace - i.e. do a lot of step intos or step overs - how should I proceed in the actual debugger?) Thanks. Jeff Bischoff wrote: Lightbulb, Take a look at the context-param: context-param description Only applicable if state saving method is server (= default). Defines the amount (default = 20) of the latest views are stored in session. /description param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION/param-name param-value20/param-value /context-param This is a myfaces thing. Basically it will store the last X number of component trees, and when a new sumbit occurs it uses the sequence number to look up the right component tree. It has no idea whether they are coming from the same or different windows. It does not overwrite the old ones until it runs out of room (that's the whole point of the sequence numbers, so you can have several copies of the same view with different component trees). I agree with Craig though, you can learn a lot from the source - much more than just looking naively at the generated output. :) Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Craig McClanahan wrote: On 12/21/06, lightbulb432 [EMAIL PROTECTED] wrote: 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! The best way to address your confusion would be to look at the actual source code, and see what actually happens for yourself. The source code for both MyFaces and the JSF RI is open source ... you'd answer your questions a lot faster by just taking a look at what actually *does* happen. Craig Jacob Hookom wrote: When a postback occurs, the ViewState is restored from the previous
RE: RE: Re: Reason behind jsf_sequence?
For the level of information you need, you could read any of them, or even find the JSF 1.1 JSR at JCP.org and read that. Should I be reading version 1.2 or version 1.2 (Revision A)? I figure that there are implementations of 1.2 but not 1.2A so if I read the latter there may be things that haven't been implemented yet in the version of JSF I'm playing with, leading to confusion? Is this correct reasoning, or is that not how revisions of final specs work? (i.e. The only changes are not changes to functionality and major things like that...) Or would a JSF implementation work to become 1.2A compatible after 1.2 then call themselves a 1.2A-compliant spec? Jacob Hookom wrote: I, personally, find reading the specifications to be the easiest route-- check out JSR 252 at the JCP.org site and download the specification PDFs to give you an introductory view into the lifecycle of JSF, then provide the gritty details of how JSF works. http://jcp.org/en/jsr/detail?id=252 -- Jacob Ok, I'll look at the source and see what I come up with. Could somebody please provide guidance as to how to get started (as I've never seriously looked at code for a real program and knew what I was doing...) I saw the wiki page that somebody posted earlier on the different classes and methods to watch out for, so I'll follow that. Do I need the source for anything apart from the 2 MyFaces JARs? (e.g. any supporting libraries that'll inevitably pop up throughout the processing?) Also, from the time I start tracing the call from the entry to Faces Servlet to the actual response being generated and sent back out, how many classes should I expect to come across in the debugger? Are we looking at thousands, or just a few, or what (yah, dumb question, but I don't know in how much detail to follow the stack trace - i.e. do a lot of step intos or step overs - how should I proceed in the actual debugger?) Thanks. Jeff Bischoff wrote: Lightbulb, Take a look at the context-param: context-param description Only applicable if state saving method is server (= default). Defines the amount (default = 20) of the latest views are stored in session. /description param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION/param-name param-value20/param-value /context-param This is a myfaces thing. Basically it will store the last X number of component trees, and when a new sumbit occurs it uses the sequence number to look up the right component tree. It has no idea whether they are coming from the same or different windows. It does not overwrite the old ones until it runs out of room (that's the whole point of the sequence numbers, so you can have several copies of the same view with different component trees). I agree with Craig though, you can learn a lot from the source - much more than just looking naively at the generated output. :) Regards, Jeff Bischoff Kenneth L Kurz Associates, Inc. Craig McClanahan wrote: On 12/21/06, lightbulb432 [EMAIL PROTECTED] wrote: 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! The best way to address your confusion would be to look at the actual source code, and see what actually happens for yourself. The source code for both MyFaces and the JSF RI is open source ... you'd answer your questions a lot faster by just taking a look at what actually *does*
RE: Reason behind jsf_sequence?
Regarding the back button problem, I have a question: So the issue is that you have an original page with a form on it (page1.html) that was obtained through a GET; the browser bar shows page1.html. You POST that form to a destination of page2.html (as defined in form) and a response is generated in whatever way and the browser bar now shows page2.html. First question: is this a postback? (Is a regular POST the same as a postback?) From page2.html, the user hits the back button...doesn't it just do a GET on page1.html and all is fine? What's the issue? I'd guess that hitting the Refresh button would cause another POST to page2.html with the same parameters, but hitting the Back button would cause a GET to page1.html...am I totally off here? 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#a8017953 Sent from the My Faces - Dev mailing list archive at Nabble.com.
RE: Reason behind jsf_sequence?
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.
RE: Reason behind jsf_sequence?
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...? How would the server generally tell which came from which window using jsf_sequence? 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? 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...) 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#a8003568 Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: Reason behind jsf_sequence?
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.
