Thank you Werner for your answer.
If I understand what you say, a stateless component doesn't exist on the
server between 2 requests, that's right ?
And a component like h:outputText doesn't need to be stateful contrary
to a more complex component like a tree, am I right ?
Werner Punz a écrit :
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.
