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