Sure,
here goes. I have added both the java and the js file to the same Java package:
WicketAjaxJsPatch.java
==================
/**
* {...@link IBehavior} that should be added to {...@link Page}s that need to
prevent
* the page load performance penalty incurred when wicket-ajax.js traverses all
* <a> tags in the page markup.
*
* <p/>
* For background information, see <a
href="http://www.nabble.com/wicket-ajax-and-IE-performance-problems-for-pages-with-many-links-td23078336.html";
* >this mailing list thread</a>
* <p/>
* This behavior simply makes sure that our patch gets applied to wicket-ajax.js
* (by forcing wicket-ajax.js to be added to the page head prior to
* wicket-ajax-patch.js).
*
*/
public class WicketAjaxJsPatch extends AbstractDefaultAjaxBehavior {
@Override
public void renderHead(IHeaderResponse response) {
super.renderHead(response);
response.renderJavascriptReference(new ResourceReference(
WicketAjaxJsPatch.class, "wicket-ajax-patch.js"));
}
@Override
protected void respond(AjaxRequestTarget target) {
// Does nothing. The fact that we are extending
// AbstractDefaultAjaxBehavior means that we will pull in
// wicket-event.js and wicket-ajax.js. The job of this behavior is to
// make sure that our wicket-ajax-patch.js script gets added to the page
// head after those scripts.
}
}
wicket-ajax-patch.js
===============
/**
* Overrides the attachFocusEvent function registered by wicket-ajax.js.
* The original version traverses all anchor and button tags on the page
* which incurs a major performance penalty on pages with many links.
* This version skips these elements in the scanning.
*/
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);
}
}
Attaching the behavior
=================
What I do then is to add the WicketAjaxJsPatch to the page by doing.
page.add(new WicketAjaxJsPatch());
It seems to be doing its job for me. Please tell me if it doesn't work.
cheers, Peter
On Fri, Apr 17, 2009 at 12:15 PM, James Carman
<jcar...@carmanconsulting.com> wrote:
> 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 <peter.gardfj...@gmail.com>:
>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
