Yeah, the headRendered flag is still set to true so the JsTimeout call is
never rendered. I'm not sure why it's was removed in the first place,
perhaps it's something to do with the precondition?
CrocodileShoes wrote:
>
> Hi,
>
> No it's definitely not that. I tried your class to be sure and it still
> doesn't work.
>
> I've done some more debugging with Firefox's Firebug and discovered that
> when I switch back to the tab with the updating behaviour it does not
> contain the evaluate part.
>
> I'll print this, it's easier:
>
> This is in the response after I switch to the self updating tab for the
> first time:
> </component><evaluate><![CDATA[setTimeout("var
> wcall=wicketAjaxGet('?wicket:interface=:5:tabs:panel:logOutput::IBehaviorListener:0:-1',null,null,
> function() {var c = Wicket.$('logOutput611'); return typeof(c) !=
> 'undefined' && c != null}.bind(this));",
> 5000);]]></evaluate></ajax-response>
>
> Now, if I navigate away, and stay away (on another tab), until the timer
> fires it fails the precondition check. When I go back to the self
> updating tab the response contains:
> </component></ajax-response>
>
> There is no evaluate section.
>
> The renderHead() seems like it is responsible for this, as follows:
>
> if (!stopped && (!headRendered || !request.isAjax())) {
> headRendered = true;
> response.renderOnLoadJavascript(getJsTimeoutCall(updateInterval));
> }
>
> Now, stopped is definitely false so one of the other if-conditions must be
> responsible. I'll do some more work on this now.
>
> Thanks for the help so far.
>
--
View this message in context:
http://www.nabble.com/Is-it-possible-to-restart-an-AjaxSelfUpdatingBehaviour-after-it-has-been-stopped--tp24626909p24646324.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
