Re: =[xhr]

I've seen that sort of code before.  Sometimes unforseen events occur 
leaving you with a nonworkable screen.  I tend to trust Javascript less 
than the environment on the server.  Yes, there are better ways to build a 

DB application than web technology, but we are presented with the 
programming challenge of adding to a portion of  DB application to an 
existing intranet application and now need the tools that will make the 
browser behave very non-web for a few moments.  Can be a challenge.

I still don't understand how this request has become a harangue to make 
sure I know that everybody thinks I am wrong to make such a request.  I 
spoke about specific situations where I found synchronous xmlhttprequests 
to be useful and based on that, I expect them to be useful in the future. 
What I get back are very general vague assertions that seem to

1. Assume I never use asynchronous xmlhttprequests (not true, I use them 
predominantly)
2. Seem to ask me to take into account all situations, imagine all 
possibilities when I am only trying to solve 1 issue on 1 screen in 1 
application

My only assertion is: when synchronous xmlhttprequests are required, async 

WILL NOT WORK and are not appropriate.  Simply repeating the mantra over 
and over is not convincing.



From:   David Bruant <bruant.d@gmail.com>
To:     nmork_consultant@cusa.canon.com, 
Cc:     Austin William Wright <aaa@bzfx.net>, Glenn Maynard 
<glenn@zewt.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, public-webapps 
<public-webapps@w3.org>
Date:   08/04/2014 08:07 AM
Subject:        Re: =[xhr]



Le 04/08/2014 15:30, nmork_consultant@cusa.canon.com a écrit :
This is an intranet application.  The server is in the next room (locked, 
of course.) 
I was seeing this one coming when I wrote my paragraph :-p
If you're in a tightly controlled environment, one could question the 
choice of a web application, but that's beyond the point of this email.

However, many (not all) POST operations require only 1 channel to be 
active at a time, especially in intranet applications.
As someone else noted, how do you know two computers aren't connected at 
the same time? Or even that the same user isn't logged in in two different 

machines within the network?
Note also that as others said, sync xhr doesn't freeze the browser, so if 
your application isn't robust to the user changing tab, or going back, you 

may have a bug you want to fix.

If your answer resembles even vaguely "because I control the environment 
and want to prevent the user from doing x, y, z and will as long as I 
can", then, I'd like to question again whether you really want to make 
your intranet application run a web browser.
There are lots of other choices to make non-web applications, but the web 
platform took the path of prioritizing the end-user concerns above all 
else. See the "Priority of Constituencies" : 
http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
We've had a foggy period at the beginning of the web, but it's clear now 
that end-users are considered as a priority in web standards and 
implementors (though obviously various parties will see end-user interests 

from a different perspective).

If you care about how your software ensures some guarantees for your 
database above providing a good user experience, the web might not be 
where you want to make your application and I think that you will keep 
meeting resistance in web standards mailing-lists.

No user wants to be given the freedom to accidentally screw up. 
Why would you write code that provides that freedom, though?
In cases like you describe, I would send the POST request asynchronously 
and then disable any user interface that allows to send another request 
until the server comes back with a 200 (or equivalent) via either removing 

the event listeners. In essence, that would look like:

    var postUrl = '...';
    postButton.addEventListener('click', function clickHandler(){
        var xhr = new XMLHttpRequest();
        xhr.open('POST', postUrl);
        xhr.addEventListener('load', function(){
            // POST came back, re-enable the button
            postButton.removeEventListener('click', clickHandler);
            postButton.setAttribute('disabled', 'disabled');
        });
        xhr.send();

        // disable UI for POSTing
        postButton.removeEventListener('click', clickHandler);
        postButton.setAttribute('disabled', 'disabled');
        // maybe add a spinner somewhere and/or invite the user
        // to have a hot beverage of their choice as you suggested
    });

Of course, disable any other UI element you need, error handling is 
missing, etc, but you get the idea.
The above code demonstrates that you can prevent the user from further 
interacting with the database, yet use async xhr.

David