> 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.
I think there's no difference between client-side and server-side tab-switching of the MyFaces panelTabbedPane regarding the rendering behaviour. I did expect that, when using server-side tab-switching, only the active tab's content would be rendered, but looking at the HTML source returned with the response showed me, that the content of all tabs is contained. The contents of the inactive tabs are only made invisible by using CSS. I use MyFaces Nightly 20051130 - maybe it's a problem with this version only. Regards, Matthias > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag > von Werner Punz > Gesendet: Freitag, 3. März 2006 00:05 > An: [email protected] > Betreff: Re: stateful/stateless JSF components > > > 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. >
