Le 04/08/2014 15:30, nmork_consult...@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
