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-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. >>> >> >> > >-- >View this message in context: >http://www.nabble.com/Reason-behind-jsf_sequence--tf2860440.html#a8010075 >Sent from the My Faces - Dev mailing list archive at Nabble.com. >
