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.
