Buttons and links dont make much sense yes. Dont remember why we should do this. Will check the code
On 16/04/2009, Igor Vaynberg <[email protected]> wrote: > this code is there so we can track focus and properly restore it after > ajax modifies the dom. i am not sure why we need to track and restore > focus on anchors, it is only important when you are typing so that the > cursor doesnt move elsewhere - so only for textfields and textareas. > > johan, matej says you wanted to track focus for anchors, whats the deal? > > -igor > > 2009/4/16 Peter Gardfjäll <[email protected]>: >> Hi James, >> >> I'm pretty sure that links are part of the problem. >> To verify this, try replacing all <a> tags with e.g. <span> and see if >> you can spot any difference in response time. >> Alternatively, try replacing/commenting out ajax components/behaviors >> on your page to prevent wicket-ajax.js from being pulled into the >> page. >> >> cheers, Peter >> >> On Thu, Apr 16, 2009 at 3:52 PM, James Carman >> <[email protected]> wrote: >>> Peter, >>> I have experienced similar problems just recently. I didn't narrow it >>> down >>> to the fact that the links were the problem, as you have, though! I have >>> been racking my brains trying to figure this thing out. My page is >>> similar, >>> a table with lots of cells in them that are links. I've turned off CSS >>> and >>> other stuff trying to find the bottleneck. I didn't think for a moment >>> that >>> it might be the links. >>> >>> James >>> >>> 2009/4/16 Peter Gardfjäll <[email protected]> >>> >>>> Hi all, >>>> >>>> I am working on a wicket application intended to be executed both on >>>> FF3 and IE7. >>>> While working on this application I have discovered that the rendering >>>> of some pages are a lot slower in IE. >>>> The pages that were significantly slower on IE have a couple of things >>>> in common: they are ajax-enabled and have lots of links. >>>> These pages all appear to freeze for a while after all data has been >>>> transferred, but before the page becomes responsive. >>>> >>>> The reason (or at least one of the reasons) is that wicket-ajax.js, >>>> which gets pulled in whenever an Ajax component/behavior is added to a >>>> page, registers a function >>>> (addDomReadyEvent(Wicket.Focus.attachFocusEvent)) that traverses all >>>> {input,select,a,textarea,button} tags in the DOM tree when the page >>>> has been loaded. >>>> >>>> I timed this function for one of my pages (containing a single big >>>> table with around 300 rows, with each row having about six links). >>>> When the function is registered, the fireDomReadyHandlers in >>>> wicket-event.js takes 2400 ms to execute, compared to 700 ms when not >>>> registered. In firefox, the corresponding numbers are about 470 ms and >>>> 400 ms. >>>> >>>> Hence, there seems to be quite a performance penalty involved in >>>> loading ajax pages with lots of links in IE7. >>>> I'm a bit worried about this overhead, particularly since I have a >>>> rather fast machine (a lot better than most of the end users anyway). >>>> I would not be surprised if clients see double page load times. >>>> >>>> Have anyone on this list experienced similar problems? >>>> Is this a known issue? (I have not been able to find anything similar >>>> on the mailing list) >>>> Any suggestions or pointers are welcome. >>>> >>>> best regards, Peter >>>> >>>> /PS By the way, I am using wicket 1.3.5. >>>> >>>> --------------------------------------------------------------------- >>>> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
