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
