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-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. >
