> How do each of these form fields help JSF do what it does? > MyFaces is a > wonderful tool, but I'd like to understand "how" it does what > it does (on a > high enough level that it might be explained in a couple of > detailed replies > to this post)...because right now it seems a bit "too" transparent and > magical.
Dude, you're getting yourself bogged down on things that you typically don't need to understand. It may seem like magic, but trust me in the end you'll save yourself some frustration by just relying on JSF to adhere to the contract it gives you. Just like Oz, you might not like what you see behind the curtain... Basically, depending upon your web.xml config parms for faces, you'll end up with a myriad of hidden fields and javascript methods. These all are in place to help the faces servlet translate an incoming request into the runtime state info needed for the jsf environment. They are hidden because you can't change them on the client w/o risking the corruption of the jsf app. The jsf app consumes them on the server and doesn't pass them to your app because they are simply for rebuilding the app to a state that your code needs it to be in to be successful. If you need to understand all of the plumbing, then your best bet is to download the source, set a breakpoint in eclipse, then follow as the incoming request is processed. But realize up front that anything you learn applies only to the version of faces you're using; the myfaces developers are free to (and often will) make changes to the generated elements to support the ongoing development effort. > When using client-side state saving, where and how is the > state saved on the > client? Are all the components serialized to the client (is > that what's > basically in those hidden fields) or what? Does the server > really store no > state whatsoever about a particular client? The serialized information for the entire view root is stored in a hidden field. You've got a state field but since it is so small I can only guess that you've got a basic form with little if any embedded components. For client side state saving, no state information will be kept on the server (your session information you've stored is still safe). You normally choose this option when you have large views to deal with or you are serving many end users; in both cases you've made the determination that you're willing to sacrafice the network bandwidth in order to conserve server memory resources. > I've read the manuals and tutorials, but I'm still confused > on these issues. Try some of the JSF books; I'm partial to JavaServerFaces in Action published by Manning. Dave
