I'm using tab panels with the ajaxtags library, and for me is very good.
Mileidys González Prieto Consultant i-Frontier Henck Arronstraat 16 | P.O.Box 12858 | Paramaribo, Suriname (SA) Office: (597)-424073 | Mobile: (597)-8810219 www.i-frontier.net -----Original Message----- From: Jeromy Evans [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2008 8:00 PM To: Struts Users Mailing List Subject: Re: Tabbed panel performance Hi Pablo, Consider creating a custom profile for dojo. This makes a significant improvement to the page load time as it reduces the number of http requests (read on first though) http://cwiki.apache.org/S2WIKI/creating-a-custom-dojo-profile-for-struts-20x .html The reload problem you're encountering is that you're either accumulating too many objects in memory or too many nodes in the DOM. Use Firebug to make sure the previous versions of the tabs are not still in the DOM somewhere. Next, you'll have to ensure the widgets objects Dojo created are released from memory before creating them again after the reload (I've never done this...not sure how to ask dojo to dispose of them), and finally you'll have to ensure any listeners attached to DOM nodes inside your tabs are released (this causes major memory leaks in IE if they're not). All of this has to be controlled using the Dojo API, not the struts 2 tags. The dojo struts2 tags in 2.1 include an attribute to control whether dojo should parse the content for widgets. This makes a significant performance improvement rendering tabs that contain a lot of markup. This feature is available in Struts 2.0 version of dojo, but not as an attribute of the Struts2 tag. Again, you'll have to dig into the Dojo/widget API to enable the feature. When I reached that point of complexity (and slowness) I stopped using Dojo and switched to another library. When you're using the Dojo API the benefit of the struts2 tags is completely lost. Most people love JQuery. I use YUI. Dojo1.x looks good too, but I was too burnt to try it. Migrating from the struts2 tags may be a significant effort if you have a lot of notifiers in there, but JQuery and YUI are such a pleasure to use compared to the Struts2 tags so I think you'll find conversion a positive experience without regret. Good luck! regards, Jeromy Evans Pablo Vázquez Blázquez wrote: > Just a bit more information. I have profiled (using firebug) the > action (always the same action with the same content) with and without > the <s:tabbedpanel> tag and here are the results: > > Without: > --- > 1727.355ms > 1424.947ms > 1748.429ms > 1523.518ms > 1539.649ms > 1606.369ms > 1657.058ms > 1599.767ms > 1632.157ms > 1564.907ms > > With: > ---- > 2294.719ms > 2513.386ms > 3398.823ms > 4414.39ms > 5716.896ms > 7383.391ms > 10188.268ms > 12604.345ms > 15876.5ms > 20576.395ms > > As you can see, executing the action with the tag multiplies by 10 the > response time!, while when not using the tag, response times are more > or less equilibrated. > > > Jeromy Evans escribió: >> Pablo Vázquez Blázquez wrote: >>> Any idea about why am I getting increasing response times each time >>> I access to the page? >>> >>> I have already a great response time the first time I access to the >>> page (which is also a problem), but my main problem is that after 6 >>> or 7 accesses it in unmanageable... >>> >>> Thanks! >> >> I don't recall the 0.4 dojo tabbed panel being particularly slow to >> render, other than the extreme initial page load while Dojo makes too >> many http requests. >> >> I can't think of any reason why it would get slower after a genuine >> page reload with the same content (if it's reloading via ajax >> though, then there's a good reason). The reload problem is not >> evident in the showcase: it's consistently unbearably slow for each >> reload at planetstruts. >> Dojo parses your html for widget markup, so it there's a lot of >> mark-up inside the tabs it's going to be slooowww (such as tables). >> >> Whenever I had a dojo problem I created a simplified page of html >> with just the one widget on it to isolate the cause. You're putting >> yourself through unnecessary torture by not using a newer client-side >> library though. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
