> Which is a good class to set the first breakpoint in, from > which I could > follow out the rest of the processing? Would it be in the > generated servlet, > in some kind of interceptor class (if using JBoss), the Faces > Servlet, or > where?
I guess if you want to know it all you'd have to start with the faces servlet. That would show you everything that occurs from the time the request arrives through the final response that is generated. > If there's absolutely no information stored on the server, > then (assuming > somebody could unencrypt the content of those fields) > technically somebody > could alter the hidden field values, resubmit the form and > see something > different from what they expected, right? Sure, but that's possible with any client side framework. As all of the data is serialized from components, I would expect this kind of hack to take more than a minimum amount of expertise. > With server-side state-saving, how is the information passed > between the > client and the server? (cookies, URL, hidden form fields?) It's not. The view root is cached on the server (I believe it is stored in the session); the incoming request will have your session identifier (JSESSIONID) (whether you're using cookies or request parameters or whatever), so when the server identifies your session the view root can be accessed. > I understand I'm asking implementation details that I don't > "necessarily" > need to know in order to use JSF, but I nonetheless need to > understand the > concepts. I think it's unwise for a developer to not know (at > least on a > conceptual level) what's going on the in framework or tool > that they're > using. Not to mention the fact that developers often (if not > VERY often) > need to justify these development choices to others within their > organizations. I agree about the conceptual level argument. State saving, IMHO, for the conceptual level means your trying to determine whether to store state on the client or the server, and each of these comes with pros and cons. Nitty gritty details about what hidden form fields are being used to stuff state information on the client side goes well beyond the conceptual level and delves deeply into the implementation details. Conceptually I am fully aware of Spring, Hibernate, JSF, and Facelets (the tools we're using), but I intentially avoid trying to understand how all of these implementations are done (I think figuring all of that out would be a full time position all of it's own). This changes, of course, when you run into a snag of some sort. But even then you have to get your hands dirty but there is a tight focus on the code which is causing you the headaches, and not the full soup-to-nuts implementation details.
