Yes.
Wicket sends a message on topic '/dom/node/removed' for each removed element.
Using its id we can stop the timer.
Please file the ticket :-)
On Wed, Aug 1, 2012 at 6:20 PM, Bertrand Guay-Paquet
<ber...@step.polymtl.ca> wrote:
> Would this work if done on the client?
>
> New code when ajax response is received :
> replacedDOMElement = ...;
> $replacedDOMElement = $(replacedDOMElement);
> for each js timers:
> $component = $(timer.component);
> if( $replacedDOMElement.is($component) ||
> $replacedDOMElement.find($component ).length ) {
>
> cancelTimer(timer);
>
> }
>
> On 01/08/2012 10:37 AM, Martin Grigorov wrote:
>>
>> I see.
>> I'm not sure how Wicket can detect this situation ...
>>
>> A workaround would require some coding from the developer - when he
>> replaces the component he has to call additionally:
>> timerBehavior.stop(target).
>> This will clear the scheduled timeout in the browser.
>>
>> On Wed, Aug 1, 2012 at 5:31 PM, Bertrand Guay-Paquet
>> <ber...@step.polymtl.ca> wrote:
>>>
>>> Yes I was using -beta3 since this is what Alex used. I just tried it with
>>> -SNAPSHOT (commit b89909c1fa99ae6973c3fb0738a966eb23c27e73) and I get the
>>> same exception.
>>>
>>> You say that:
>>>
>>>
>>> The precondition checks that the component (html element) on which is
>>> attached the timer behavior is still in the DOM document.
>>>
>>>
>>> In this case, the component id is still in the DOM (it was replaced by
>>> another one by the same id). The problem is that on the java side, the
>>> component is different and does not have a timer behavior attached, hence
>>> the callback fails.
>>>
>>>
>>> On 01/08/2012 10:14 AM, Martin Grigorov wrote:
>>>>
>>>> Do you use -beta3 ?
>>>> There was a bug which is fixed in -SNAPSHOT. That's why I know how it
>>>> works ;-)
>>>>
>>>> On Wed, Aug 1, 2012 at 5:12 PM, Bertrand Guay-Paquet
>>>> <ber...@step.polymtl.ca> wrote:
>>>>>
>>>>> On 01/08/2012 9:58 AM, Martin Grigorov wrote:
>>>>>>
>>>>>>
>>>>>> No.
>>>>>> The timer is fired but the precondition prevents the Ajax call.
>>>>>> The precondition checks that the component (html element) on which is
>>>>>> attached the timer behavior is still in the DOM document.
>>>>>
>>>>> Hmm... I don't quite know what to say! In my tests, the timer is still
>>>>> fired
>>>>> event after its attached component is replaced.
>>>>>
>>>>> Here is the sequence of requests captured in Firebug:
>>>>>
>>>>> Ajax Request 1 (timer callback):
>>>>>
>>>>> http://localhost:8080/?2-1.IBehaviorListener.0-fragments&_=1343829988777
>>>>> <ajax-response>
>>>>> <evaluate>Wicket.timerHandle_fragments3 =
>>>>>
>>>>>
>>>>> setTimeout('Wicket.Ajax.ajax({\"u\":\"./.?2-1.IBehaviorListener.0-fragments\",\"c\":\"fragments3\"});',
>>>>> 2000)</evaluate>
>>>>> </ajax-response>
>>>>>
>>>>> Ajax Request 2 (click ajax link to replace the component "fragments"):
>>>>> http://localhost:8080/?2-1.IBehaviorListener.0-remove&_=1343829990235
>>>>> <ajax-response>
>>>>> <componentid="fragments3"><span wicket:id="fragments"
>>>>> id="fragments3">WMC</span></component>
>>>>> </ajax-response>
>>>>>
>>>>> Ajax Request 3 (timer callback):
>>>>>
>>>>> http://localhost:8080/?2-1.IBehaviorListener.0-fragments&_=1343829990803
>>>>> Throws exception:
>>>>> org.apache.wicket.behavior.InvalidBehaviorIdException: Cannot find
>>>>> behavior
>>>>> with id '0' on component
>>>>> 'org.apache.wicket.markup.html.WebMarkupContainer:fragments' in page
>>>>> '[Page
>>>>> class = com.mycompany.HomePage, id = 2, render count = 1]'. Perhaps the
>>>>> behavior did not properly implement getStatelessHint() and returned
>>>>> 'true'
>>>>> to indicate that it is stateless instead of returning 'false' to
>>>>> indicate
>>>>> that it is stateful.
>>>>>
>>>>> (this is a different exception than reported by Alex, but it looks like
>>>>> the
>>>>> same symptom)
>>>>>
>>>>> IMHO, the AjaxTimerBehavior should have been removed during the request
>>>>> #2
>>>>> since the replacement component does not have it attached.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
