Answers below (in-line). Please (anyone) feel free to correct any mistakes I may have made...
On 5/17/07, lightbulb432 <[EMAIL PROTECTED]> wrote:
Somewhere in the months of learning and reading about JSF, I've lost touch with the basic concepts. Could somebody please explain why state for the view needs to be stored to begin with?
Well, with facelets, it doesn't really
Could JSF be used in a stateless manner, or is that not how it is meant and designed to be used?
For the most part yes, but probably not desirable
How do alternatives to JSF like Struts, Struts2, and others handle the concept of view state?
The don't, they have no component state
I realize this is a total newbie question, but I hope you can explain in clear and thorough terms the concept of JSF as it relates to other frameworks out there – I can't conceptualize it easily, even after having played around with it for a little while.
JSF is built around components and component states. The idea is to produce a web framework that acts much like a GUI framework like Swing, but for the web. The component tree is like the AWT/Swing component instances that make up a JFrame (for example). Each component in a JFrame has properties. Those properties could be simple ones, like foreground color, or complex ones like a tree model. When a JSF view is rendered, the view is serialized down into its state. The actual components are not stored, but their state is. This is done by calling componet.saveState recursively on all components in the component tree that are not transient. Now, JSP requires a "heavy" implementation of the view state because once the JSP tags build the components, there is no way to rebuild the same component tree during the restore view phase on the next request. It therefore needs to store everything about the components, including all the value bindings and other attributes. Facelets on the other hand uses an XML representation of the view that allows the FaceletsViewHandler to create a component tree directly from that XML, skipping the tag->component "phase". It has the information to reset all the value bindings an other attributes on each request and do so reliably. Unfortunately for us facelet users, the view state is still saved as per needed by JSP and therefore is not optimized for a technology like facelets (hopefully JSF 2.0 will continue improving this). Also, some component developers choose to save state like if a tree node is expanded or not in the component and not as part of an external object (like a tree model or a tree state). Should the backing beans store all the component specific information that stores data state, then the component tree is entirely not needed at all in a facelets environment. See the following blog posts on going stateless: http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin_1.html http://sfjsf.blogspot.com/2006/01/should-jsf-go-stateless.html
Thanks. -- View this message in context: http://www.nabble.com/Philosophy-of-JSF-tf3772976.html#a10667738 Sent from the MyFaces - Users mailing list archive at Nabble.com.
