[jira] Resolved: (WICKET-745) AbstractAjaxTimerBehavior triggered more than expected after a new Ajax rendering

["Gerolf Seitz (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gerolf Seitz resolved WICKET-745.
---------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 1.3.0-beta4)
                   1.3.0-rc2

fixed.
instead of not rendering the head if the current request is an ajax request ( if (!stopped &&  request.isAjax() == false) ),
the AbstractAjaxTimerBehavior now stores whether the head has already been rendered (ajax or normal request don't matter) or not
in private boolean headRendered, like this:

private boolean headRendered = false;

// in renderHead
if (!stopped && !headRendered)
{
	headRendered = true;
	response.renderOnLoadJavascript(getJsTimeoutCall(updateInterval));
}

i also updated the unit test to reflect this change

> AbstractAjaxTimerBehavior triggered more than expected after a new Ajax rendering
> ---------------------------------------------------------------------------------
>
>                 Key: WICKET-745
>                 URL: https://issues.apache.org/jira/browse/WICKET-745
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.3.0-beta2
>            Reporter: Xavier Hanin
>            Assignee: Matej Knopp
>             Fix For: 1.3.0-rc2
>
>
> When an AbstractAjaxTimerBehavior is rendered in an AjaxResponse due to another Ajax callback than the one triggered by the timer itself, it sends a new setTimeout javascript call to the client, causing the client to call the timer more frequently than expected: x+1 times as expected, where x is the number of times the behavior is rendered in a separate Ajax response.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.