There are no clear cases where you should or should not use it. It depends on the experience you want to give the user.
First of all, one of the most common but very common mistakes that I see in applications that use AJAX or other similar technologies is that there is no fallback. That is, if for some reason the technology is not available, the page does not work. The first thing you should worry is whether sending with simple HTML is working perfect in all situations. Then think about giving a slightly better experience if it is available. But don’t let the page stop working because the browser doesn’t support the technology.
Although it’s like, I think this technique is worth even when the fallback is not required by the customer, where it can be guaranteed that the resource is available. I think the cost is very low and avoids a lot of future headache. It’s a matter of methodology and organization. The cost of disorganization is usually higher. Of course the experience of each one will make choose the best way.
I’m not against people who don’t want to fallback when it is not really needed according to requirements. I just find a worse and more disadvantageous way. And the customer is not always right. Most of the time I decide for him. He decides when he knows, is reasonable or I need the money :P You will do whatever is best for you.
Functioning of the AJAX
The only great advantage that AJAX brings is that you don’t have to upload another page, or the same one again, to send the data and have a response. This is done transparently for the user. It gives a better impression, is usually faster (I’ve seen people manage to slow down) and can reduce the volume of data traffic. But nothing very important. The experience really counts.
Eventually the script PHP that will receive the request needs to be adapted to meet the need of AJAX, but does not change in a way that prevents normal access. If so, create two scripts, one to answer the form by normal sending generating a full page and the other sending only the confirmation data that the operation was successful and inform something else that is relevant. If you know how to do the job it’s almost the same.
Advantage in your case
Sending each answered question really can be very interesting.
Whether or not data is lost will depend on your script PHP know how to manipulate this. It will have to persist somewhere (database, memory, etc.), have session control, etc. You will have to control the status of the form not being fully filled in, have garbage collection policies if a form is dropped in the middle. Anyway, there are several things to think about if you want to give a good user experience.
Have you ever wondered if there is a problem at the time of sending and you don’t have AJAX? The loss is huge. With AJAX done the way you’re thinking, either take advantage of the part that’s already been done, or stop the user from wasting their time on something that will serve no purpose.
It’s all complicated, having a fallback It’s simple. That’s why many sites prefer not to have AJAX. The cost of putting this feature the right way increases, but then who pays the cost is the user who will have a much worse experience.
If you’re doing something real, even if you’re testing yet, and you’re having specific questions, you look up whether you already have it here or ask.
My answer is: You decide. Srsrsrsrsrsrs
– Wallace Maxters
@Wallacemaxters And mine is, The client decides. :D
– Caffé
In time: when I say "customer," I don’t just mean Your Joe who owns the bakery. Software client can be a complex entity with many forms.
– Caffé