[
https://issues.apache.org/jira/browse/WICKET-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495296
]
Matej Knopp commented on WICKET-556:
------------------------------------
Well. While this can certainly solve this problem for most cases, there can
still be an invalid request.
wicketAjaxGet doesn't fire AJAX request immediately. Rather than that, it puts
the request in a queue. If another requests in queue that was executed before
this one removes the component, the exception will be thrown again.
What we probably need is some kind of precondition, that would be evaluated
immediately before firing the request.
> Prevent setTimeout for AjaxSelfUpdatingTimerBehavior from firing after its
> contributing component has been replaced
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-556
> URL: https://issues.apache.org/jira/browse/WICKET-556
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Reporter: Jim McLaughlin
> Assigned To: Matej Knopp
>
> Currently, the setTimeout for an AjaxTimerBehavior will fire after the
> contributing component has been replaced or removed through an ajax request.
> This will result in an exception server side and a full page refresh client
> side.
> One possible solution is to override getCallbackScript() to enclose the ajax
> callback in another function that will only execute the ajax request if the
> markup for the contributing component is still in the dom tree:
> protected CharSequence getCallbackScript(boolean
> recordPageVersion)
> {
> String mId = getComponent().getMarkupId();
> StringBuilder sb = new StringBuilder("exec_func(function() {
> ");
> sb.append("var el = wicketGet('" + mId + "'); ");
> sb.append("if(null != el) {");
> sb.append(super.getCallbackScript(recordPageVersion));
> sb.append("}");
> sb.append("})");
>
> return sb.toString ();
> }
> Other options are to have the request cycle swallow the "component not found"
> exception for timer behaviors (since they will only fire 1 extra time)
> or
> a more complicated scheme would involve wicket actively managing javascript
> timer tokens client side so that they can be removed with clearTimeout when
> their contributing component is removed through an ajax request. The
> javascript to do this would be trivial (a simple container object mapping dom
> id to timer token), but the wicket lifecycle would need to support an
> onRemove callback for components to perform cleanup.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
