It's not quite that straightforward; if each tab is showing results of a different query, loading all the content up front can result in a brutal load time for the first page. You could end up significantly increasing the load on the database tier.
There's lots of trade-offs to consider; user performance, app server scalability, database scalability, etc. -- Adam On 3/3/06, Werner Punz <[EMAIL PROTECTED]> wrote: > I dont know, I do not know the code of this component too much, anyway > my point was that if you do client side tab switching you reduce server > side load tremendously, either way in any case because with client side > tab switching you trigger only one request at all. > > And I think adding some stateful behavior on the client generally can > help to resolve a lot of problems, where the server nowadays still has > to keep the load and state saving. > > And if it is true what you say then the load savings due to the client > side tab switching on the myfaces tabbed pane is even more, because you > stream the entire data only once instead of at hitting the tab every time. > > > > > Matthias Kahlau schrieb: > >> 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. > > > >
