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-name>org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION</param-name> > <param-value>20</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 >>> >> 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. >>> >>> >> > > > > -- View this message in context: http://www.nabble.com/Reason-behind-jsf_sequence--tf2860440.html#a8009539 Sent from the My Faces - Dev mailing list archive at Nabble.com.
