>From: "Ted Husted" <[EMAIL PROTECTED]> > > On 5/17/07, lightbulb432 wrote: > > How do alternatives to JSF like Struts, Struts2, and others handle the > > concept of view state? > > For the most part, they don't have the concept of View State. If a > control uses data that is not in the post, and the page needs to be > presented again (because, say, validation failed), then an > action-based framework will go and fetch the control data again. (In > fact, Struts 2 has a special "prepare" method that is used to create > (or recreate) "View State".) If the data in question is semi-static (a > drop down list), and the query is cached, then it's a memory-to-memory > transfer, otherwise, we have to hit the database again. The trade-off > having JSF automatically process the encoded view state field (whether > you need it again or not). >
I think it's also worthwhile to point out that *most of the time*, the JSF view state represents the properties of the JSF components and not the "view model". Component properties are used to fixup the expressions (EL) that JSF uses to bind to data and backing logic. The same component is reused multiple times and its properties defines its behavior. Since JSF is component centric, each component is responsible for acting on the results of a form postback. The components are also responsible for rendering markup. When a post back occurs, JSF restores the component tree for a page. The JSF lifecycle just recursively broadcasts to the component tree starting at the view root. The act of restoring the component tree makes the graph of components realize their behavior. This pattern is similar to commons chains. If you defined a chain that processed the results of a postback, the graph of commands would have to be glued together someplace. Each command might need specific properties for a given path/viewId so that the same command could be reused in various pages. > -Ted. Gary
