[
https://issues.apache.org/jira/browse/WICKET-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580647#comment-13580647
]
Didier Villevalois commented on WICKET-5039:
--------------------------------------------
Hi,
I did not see this issue and commented on the issue that broke the use of
identifier|jscode as permited by wicket-ajax-jquery.js (see
https://issues.apache.org/jira/browse/WICKET-4881)
Let me give an explanation of how I use this feature:
Lets say you have a open modal window (ala bootstrap) you want to close it,
change its content and reopen it in a single ajax request. For that you need to
delay the component replacement until the javascript effect that closes the
modal window. That animation is asynchronous, so the only way to do that is to
register for the event triggered when the modal is effectively closed and call
the notify() callback so that FunctionsExecuter can continue its processing.
The identifier|jscode feature can not be called anymore since
https://github.com/apache/wicket/commit/cbf76d0e8c355876e302699c0975971773941ae9
as the code is concatenated and each evaluation encapsulated in a '(function()
{ jscode })();' statement.
A good solution for me would be:
1) Introduce a protected JavaScriptFragment object in AbstractAjaxResponse
protected class JavaScriptFragment {
private String notifyCallbackName;
private String script;
// + constructors and getters
}
2) Provide new APIs on IJavascriptResponse:
void prependJavaScript(String script);
void prependJavaScript(String notifyCallbackName, String script);
void appendJavaScript(String script);
void appendJavaScript(String notifyCallbackName, String script);
and deprecate addJavascript(..) as this is not very descriptive of where the
script goes in the response (also its current implementation does not take
profit of script concatenation).
3) Make AbstractAjaxResponse collect JavaScriptFragments and decide itself what
it can concatenate (it is not the responsability of AjaxXmlResponse to do so is
a json-based response would have the same problems with browser-specific
limited call stacks). We can concatenate scripts without callback use but can't
concatenate scripts with explicit callbacks, right ?
4) Make AbstractAjaxResponse define
protected abstract void writePriorityEvaluation(Response response,
String script, String callbackName (may be null))
protected abstract void writeNormalEvaluation(Response response, String
script, String callbackName (may be null))
and use that in writeTo(..) to pass concatenated scripts or individual script
with callback name.
What do you think ? We could also (not disjunctive with the solution above)
introduce additional APIs in wicket-ajax-jquery.js processEvaluation() to
handle something like this:
<[priority-]evaluate>
function(scripts) {
scripts.queueAsync(function() { jscode });
scripts.queueAsync(function() { jscode });
scripts.queueSync(function(notify) { jscode that calls notify });
scripts.queueAsync(function() { jscode });
scripts.queueAsync(function() { jscode });
// ....
}
</[priority-]evaluate>
Such a queue would then be processed serially avoided the IE problem and still
providing the possibility to delay component replacement.
Any thoughts ?
> ajax post call handlers might not get called because of failure on AJAX
> processEvaluation function
> --------------------------------------------------------------------------------------------------
>
> Key: WICKET-5039
> URL: https://issues.apache.org/jira/browse/WICKET-5039
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.21, 1.5.8, 6.5.0
> Environment: any
> Reporter: Ernesto Reinaldo Barreiro
> Priority: Trivial
> Attachments: WICKET-5039.patch, wicket5039.tar.gz
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> We are having problems on Wicket 1.4.x with and "AJAX function"
> processEvaluation... and I see the code is practically the same at 6.x. So,
> let's bring the subject to the list...
> Our problem is that after evaluating some expressions with errors, screen
> "freezes" because post-call handlers are not called. Problem seems to be
> related to the code.
> // test if the javascript is in form of
> identifier|code
> // if it is, we allow for letting the
> javascript decide when the rest of processing will continue
> // by invoking identifier();
> var res = text.match(new
> RegExp("^([a-z|A-Z_][a-z|A-Z|0-9_]*)\\|((.|\\n)*)$"));
> if (res !== null) {
> var f = jQuery.noop;
> text = "f = function(" + res[1] + ") {"
> + res[2] + "};";
> try {
> // do the evaluation
> eval(text);
> f(notify);
> } catch (exception) {
>
> Wicket.Log.error("Wicket.Ajax.Call.processEvaluation: Exception evaluating
> javascript: " + exception + ", text: " + text);
> }
> }
> In case of error. Shouldn't it be
> try {
> // do the evaluation
> eval(text);
> f(notify);
> } catch (exception) {
>
> Wicket.Log.error("Wicket.Ajax.Call.processEvaluation: Exception evaluating
> javascript: " + exception + ", text: " + text);
> notify();
> }
> So that next steps in processing get called. The above solves or freezing
> problem in case of error
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
