Can you wait for javascript callback?

Question

I\'m trying to use the jQuery alerts dialog library from http://abeautifulsite.net/notebook/87 instead of the default alerts (which look pretty awful in my opinion). This se

Answer 1

Technically, yes, but I wouldn't do that on a website.

Take a look at Narrative JavaScript, which is based off Narcissus.

Narrative JavaScript is a small extension to the JavaScript language that enables blocking capabilities for asynchronous event callbacks. This makes asynchronous code refreshingly readable and comprehensible.

Selenium uses this technology.

---

Update

Check out JavaScript Strands:

JavaScript Strands adds coroutine and cooperative threading support to the JavaScript language to enable blocking capabilities for asynchronous event callbacks. This makes code that utilizes asynchronous operation much more linear, readable, and manageable. Strands is built upon Narrative JavaScript written by Neil Mix, and much of Narrative JavaScript has remained in Strands including much of this documentation.

In JavaScript your code can't simply wait until an event has fired -- the event must always be handled by a separate, asynchronous event handler. Sometimes this is fine, but it often forces what ought to be a simple sequence of statements into gnarly contortions. It also breaks the ability to encapsulate functionality because calling functions must know to provide a callback handler. Strands provides the ability to suspend and resume threads of execution. Execution can suspend resume when the event is finished. This allows you to write hard-to-read asynchronous event handling in simple, linear, readable code that encapsulates implementation.

Answer 2

I would assume you'd have to grab the response like this. I don't think you need a callback.

function confirm() {
        var response = jConfirm('are you sure?', 'Confirmation Dialog');
        if (response) {
            alert(result);
        }
        else {
            //wait for response
            alert('hi');
        }
    }

Answer 3

How the dudes said, there is no way! but... how we use to say in my country (Brazil), le gambi:

we can do something like it:

<h:commandLink styleClass="linkValor xExcluir" value="x"  
                     onclick="if(confirmar('Confirmar excluir.','Deseja realmente excluir este registro?', this)) return true; else return false;"
                     action="#{mBeanPesquisarLinhas.excluir}"/>

and the javascript:

function confirmar(titulo, msg, elemento) { 

    if ($(elemento).attr('sim')) {      
        $(elemento).removeAttr('sim');      
        return true;
    } else if ($(elemento).attr('nao')) {       
        $(elemento).removeAttr('nao');      
        return false;
    } else {
        $("#dialog-confirm").html('<p>' + msg + '</p>').dialog({
            resizable : false,
            height : 200,
            modal : true,
            title : titulo,
            buttons : {
                "Sim" : function() {
                    $(this).dialog("close");
                    $(elemento).attr('sim', 'sim');
                    $(elemento).click();
                },
                "Não" : function() {
                    $(this).dialog("close");
                    $(elemento).attr('nao', 'nao');
                    $(elemento).click();
                }
            }
        });
    }

    return false;
}

it's the same problem but using jquery-ui.

Bye and I hope this can help somebody.

Answer 4

I think I have come up with a possible solution to this problem. I was reading this article: http://treasure4developer.wordpress.com/2008/06/23/calling-postback-event-from-javascript/

Basically the idea is that you force the postback from javascript, at first I found that the postback would work but wouldn't call my button event, but after reading the article I found that I could detect if it was javascript postback and just call a method to do the processing

Regards DotnetShadow

Answer 5

jConfirm('are you sure?', 'Confirmation Dialog',
    function(r) {
        result = r;
        response = true;
        return r;
    }
);
if (response == true) {

This betrays a misunderstanding of the sequence of events that occurs using asynchronous code. Just because you've written it inline doesn't mean it's going to execute strictly top-to-bottom.

1. jConfirm is called, receiving a function as one of its parameters, which it remembers.
2. jConfirm displays its UI on the page and returns immediately.
3. The 'if (response==true)' line executes. Really this should just read 'if (response)', the boolean comparison is superfluous. But in any case response is of course false. Your function gives up and exits, giving control back to the browser.
4. The user clicks jConfirm's UI.
5. jConfirm only now jumps into action and calls back the function you gave it and it remembered earlier.
6. Your nested function sets response true, far too late for the 'if (response==true)' condition to do anything with it.

You have written "//wait for response" as an alternative, but there is no JavaScript code you can write that will actually do that. Your function must return to give control back to the browser, before the browser can fire the click events on the jConfirm UI that make processing proceed.

Ways to make asynchronous code work in a synchronous context (and vice versa) exist - in particular threads and coroutines (and their limited relation generators). But JavaScript has none of these features, so you must write your code to fit the synchronous-or-asynchronous model your library is using.

Answer 6

You've just hit a big limitation in JavaScript. Once your code enters the asynchronous world, there is no way to get back to a classic procedural execution flow.

In your example, the solution would be to make a loop waiting for the response to be filled. The problem is that JavaScript does not provide any instruction that will allow you to loop indefinitely without taking 100% of the processing power. So you will end up blocking the browser, sometimes to the point where your user won't be able to answer the actual question.

The only solution here is to stick to the asynchronous model and keep it. My advice is that you should add a callback to any function that must do some asynchronous work, so that the caller can execute something at the end of your function.

function confirm(fnCallback) 
{
    jConfirm('are you sure?', 'Confirmation Dialog', function(r) 
    {
        // Do something with r 

        fnCallback && fnCallback(r); // call the callback if provided
    });
}

// in the caller

alert('begin');

confirm(function(r)
{
    alert(r);

    alert('end');
})