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 seems to be a great library, but there is not an example of how to use the jConfirm library.

I need to do something like this:

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

and my call from my .net button:

I've posted a comment on the plugin's website (just this morning) and did Google searches for javascript and waiting for a callback to complete with no results.

Any ideas on how to use the callback correctly to get the result, before the rest of the javascript executes?

Thanks.

Answer 1

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 2

Since the callback is asynchronous (at least, in the sense that it's waiting on the user to do something), it might be easier to handle what you need to inside the callback:

function confirm() {
    jConfirm('are you sure?', 'Confirmation Dialog', function(r) {
        if (r) doSomething();
    });
}

---

@klogan [comments]

I assume you got these from here?

The page gives you your answer: (look under Usage)

These methods do not return the same values as confirm() and prompt(). You must access the resulting values using a callback function. (See the demo for more details.)

---

@klogan

The point I'm trying to make is that there isn't really an easy way to accomplish what you want. Your trying to correlate procedural and event-driven programming -- something JavaScript doesn't help you do.

The simplest (though, risky) solution is to use a pseudo-infinite-loop. But, if callback never gets called, you now have an actual infinite loop. And, depending on the JavaScript engine, you might kill the browser waiting.

Point: Your best bet is to avoid this trying to force event-driven into procedural.

function confirm() {
    var result = false;
    var response = false;

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

    while(!response) continue; // wait
    return result;
}

Answer 3

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 4

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 5

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');
})

Answer 6

Thanks for all the replies. It seems that this plugin isn't as easy to implement as the authors insist. Even Vincent's solution, though it may work (I haven't tried yet), doesn't seem to be the author's intent.

I'll wait to hear from the authors and post the solution. Maybe they hadn't finished it themselves. If there isn't a good solution, I'll let you know too. This is a new plugin (less than a month old).

Answer 7

Hi there,

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