Thanks for your response. The tree model and tree state you mentioned as part of the "external object", by that do you mean HttpSession state as opposed to component state?
Is server-side component state saved to the HttpSession? For frameworks apart from JSF, if they want to retain the "component state" (meaning the way their page looks, as I realize they don't have components), how do they do it - just store variables in the HttpSession, then have their JSP code output HTML based on the values of those variables? In this case, aren't JSF and other frameworks very similar in this way? Andrew Robinson-5 wrote: > > 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. >> >> > > -- View this message in context: http://www.nabble.com/Philosophy-of-JSF-tf3772976.html#a10669147 Sent from the MyFaces - Users mailing list archive at Nabble.com.
