On Wed, 2007-08-08 at 23:53 +0100, Francisco Passos wrote: > Simple jsf apps can be written without session-scoped beans, > but it > takes some effort to avoid them in larger apps. The > t:saveState tag > doesn't really scale ;-) > > It's a shame to hear that... :( > > I guess this means "back to the drawing board". > > What kind of a scale are we talking about that makes t:saveState not > work as efficiently as one would like? > > And what is the main impact? Bandwidth? Server processing due to > constant serialization / desserialization of beans being kept from > previous requests? > > These are things important to take in consideration when deciding what > to go for at application design time, because after you commit either > to session or saveState, it gets hard to go back pretty quick.
I didn't mean that there was a performance problem with t:saveState; there isn't one AFAIK. Although as an app gets more complex, the set of backing beans relevant to a page probably increases, and that will of course increase the amount of data that needs to be serialized and held by the t:saveState component. I guess that there is little impact when using server-side JSF state as that data needs to be held in either the session or the tree one way or another (though the JSF tree always gets serialized while the http session only gets serialized when memory is short). However if client-side state is being used then obviously that would increase bandwidth. However when an app gets up to 50 or 100 pages I expect that managing state by adding t:saveState tags all over the place will become hard to maintain. Some kind of "conversation" scope should be much easier to work with. Regards, Simon
