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 <peter.gardfj...@gmail.com>:
> 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 <igor.vaynb...@gmail.com>
> 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
>> <jcar...@carmanconsulting.com> 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 <igor.vaynb...@gmail.com>
>>> 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 <peter.gardfj...@gmail.com>:
>>>>> 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
>>>>> <jcar...@carmanconsulting.com> 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 <peter.gardfj...@gmail.com>
>>>>>>
>>>>>>> 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: users-unsubscr...@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
