The complexity of using t:saveState will probably depend on your application.
I've got an application with more than 100 pages, but most of the uses of those pages are self-contained. The t:saveState needs are either self-contained in a specific page or only span a small number of pages. On 8/9/07, simon <[EMAIL PROTECTED]> wrote: > 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 > > >
