Did that code actually work for you? I tried adding this js, but i couldn't get it to show up in the correct place. And, when I did, it didn't seem to improve much. Care to share your code?
2009/4/17 Peter Gardfjäll <[email protected]>: > I have written a simple WicketAjaxJsPatch Behavior which simply adds > the aforementioned javascript to the page. > In our application, we have several pages that suffer from the same problem. > It would be tedious to have to update all of these pages one-by-one. > So is there any way for me to add this Behavior to my parent page > (which other pages extend) and still have the javascript rendered last > in the head? > > regards, Peter > > 2009/4/17 Peter Gardfjäll <[email protected]>: >> Thanks Igor, >> >> the suggested workaround seems to work fine. However, it is not enough >> to just override the attachFocusEvent function -- you also need to >> deregister the previously registered function. I did as follows (I >> apologize for the lack of elegance, I'm not a js expert): >> >> if (typeof(Wicket) != "undefined") { >> if (typeof(Wicket.Focus) != "undefined") { >> // Deregister old attachFocusEvent function >> handlers = Wicket.Event.domReadyHandlers; >> filteredHandlers = new Array(); >> for(i = 0; i < handlers.length; i++) { >> if (handlers[i] != Wicket.Focus.attachFocusEvent) { >> filteredHandlers.push(handlers[i]); >> } >> } >> Wicket.Event.domReadyHandlers = filteredHandlers; >> >> // Redefine and re-register attachFocusEvent >> Wicket.Focus.attachFocusEvent=function() { >> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input")); >> >> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select")); >> >> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea")); >> >> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button")); >> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a")); >> } >> Wicket.Event.addDomReadyEvent(Wicket.Focus.attachFocusEvent); >> } >> } >> >> >> By the way, I believe that this is, or has the potential of becoming, >> a major stumbling block for others. >> Should it be regarded as a bug? >> >> kind regards, Peter >> >> >> On Thu, Apr 16, 2009 at 6:23 PM, Igor Vaynberg <[email protected]> >> wrote: >>> you can try adding this to the head after wicket-ajax.js >>> >>> <script> >>> if (Wicket!="undefined") { >>> if (Wicket.Focus!="undefined") { >>> Wicket.Focus.attachFocusEvent=function() { >>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("input")); >>> >>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("select")); >>> >>> Wicket.Focus.setFocusOnElements(document.getElementsByTagName("textarea")); >>> >>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("button")); >>> //Wicket.Focus.setFocusOnElements(document.getElementsByTagName("a")); >>> } >>> } >>> } >>> >>> >>> -igor >>> >>> On Thu, Apr 16, 2009 at 9:16 AM, James Carman >>> <[email protected]> wrote: >>>> So, we understand what's slowing us down? Any way to turn that stuff >>>> off on our end to get stuff working? I've got a release going out the >>>> door that's slow as heck on IE right now. >>>> >>>> On Thu, Apr 16, 2009 at 12:03 PM, 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] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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]
