Thomas DELHOMENIE schrieb:
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 ?
well in certain situations it makes sense to have outputtext being state
aware but in many not, and that is the real problem.
In a classical rich client ui every component you use is state aware per
default without any costs, but adding that layer to a server side
rendered ui on top of a stateless protocol is a huge burden.
The main problem is where do you draw the boundaries of having to have a
stateful component and a non stateful.
<h:outputText value="show this text"/> for sure can be non stateful
with
<h:outputText value="#{something dynamic}"/> you already might have a
problem on your hands in some conditions.
(output text probably is a bad example nevertheless lets leave it)
So where do you draw the line and where can you draw it automatically.
I am not sure if it is a good idea to go entirely stateless, you would
lose the biggest advantage of jsf the programming model of a rich client
ui that way, you would end up with a simplified Struts.
I only see two solutions, give the users the opportunity to turn off the
stateful behavior on component level, and the one Adam Winer was
showing, improve the state saving on algorithmic level. (After reading
Adams blog, I see a huge potential here)
But at one point there always will be a tradeoff, but that tradeoff has
to be done manually on non stateful frameworks as well, with myriads of
hidden fields or session states kept around programmatically to keep the
ui states.
Becoming more dynamic on the client side also might be a reduction on
the burden, not because you reduce states that way (after all the ajaxed
and javascripted ui states have to survive a request cycle) but because
you can reduce server side load tremendously that way.
The classical example is a tabbed pane. With a server side rendered, you
trigger a request at every tab change going through all the hoops, with
a client side one, you have to do more loading upfront because you load
all the components and values, but in the best case that is it, even if
you switch the tabs 100 times you wont trigger any other request onto
the server until save is hit.
