Ted Husted schrieb: > > 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). > Besides that you cannot really do a decent server side based event processing on top of something like html without some kind of state saving, it all comes down to the problem you described, do you want to hit the db and store or traverse additional data manually or have the framework doing it for you.
The classical example is the savestate component which pushes bean values over request boundaries without the html inherent hidden field cascades normally needed in every form on the page. All is done via the save stating, which serializes the bean at the end of the request and deserializes it before applying request values.
