Well, it kinda does. You can submit the links and buttons with
keyboard - and when you do it does make sense to preserve focus when
you replace the submitting button or link.
-Matej
On Fri, Apr 17, 2009 at 9:48 AM, Johan Compagner <jcompag...@gmail.com> wrote:
> 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 <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
