[
https://issues.apache.org/jira/browse/WICKET-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544667
]
Matt Clark commented on WICKET-745:
-----------------------------------
The problem with this change is that it prevents an AbstractAjaxTimerBehavior
(and this an AjaxSelfUpdatingTimerBehavior) from being initially added via
Ajax. Our app is basically a single-page application, and we need to be able
to add a component to he page and have it start updating itself. This broke
completely with Beta4 because of this change.
If there is a workaround I can't see right now, I would be happy to implement
it. Perhaps subclass and override onRenderHead? I imagine we would run into
the same problem that you were trying to fix here.
> 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-beta4
>
>
> 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.
