I've written a couple blog entries on this: http://sfjsf.blogspot.com/2006/01/should-jsf-go-stateless.html
... and this morning's: http://sfjsf.blogspot.com/2006/03/how-were-going-to-fix-jsf-state-saving.html Cheers, Adam On 3/2/06, Werner Punz <[EMAIL PROTECTED]> wrote: > Thomas DELHOMENIE schrieb: > > Hi, > > I'm reading some articles that argue on the state saving method of the > > JSF components. > > I don't really understand what they mean by talking about stateless and > > stateful, and what's the differences between these 2 methods. > > Can somebody give me an little explanation ? > > > I hope I get it right ;-) > We are in a server side rendered environment here and try to emulate a > rich client programming model. > So we have a gui with a table, a tab control and a tree. > In a normal ui all the components know their states, for instance which > tab is chosen which part of the tree is open etc.. events are triggered > which then are handled, all within the same context. > > Now we have this nasty thing html, which only knows how to render itself > and basic form mechanisms no states of components, no events except > simple form actions nothing, > > JSF and other component oriented frameworks try to eliminate this > deficiency by adding another state layer on top, so that components know > their states over the request cycle. This is done usually either by > client side or server side state saving. Client side, lots of hidden > fields, cookies or whatever are dragged along while the user interface > changes, server side the components serialize their state away and then > recycle it after the are gone over the request boundaray, load it and > then during rendering reuse it to reflect user interface changes. > > the main problem with this approach (you probably read the Hookoom blog) > is that it is very generic and a form can consist of hundreds of user > interface elements all of them doing the serialisation thing. JSF > already uses a lightweight serialisation approach, but for really high > loads with lots of users this might still be way to problematic (have in > mind that state saving is a burden on the server ramwise and also > processor time wise), many of those components often do not need an > expensive state saving cycle only some of them do. > > > I hope that sums it up. > >
