Comments on the implementation
Web browser compatibility
That said, there are a couple of things that should be mentioned:
var httpReqObj = new XMLHttpRequest();
You may have noticed that there is no exception handling at all in the source code. I chose to leave that out to keep the example down in size, but in a “real” application you should of course make sure that the code can detect and handle any errors that occur. Mind you, it is not certain that you need to, or even should, do anything when a request fails. Sometimes it’s actually better to just ignore failures for non-critical requests.
When a request is completed (
readyState == 4), and the returned
status is anything but
200, it means that there was no response from the server, or that the response was invalid in some respect. Assuming that you sent the request to the correct URL, and that the web server is running, this typically means that your PHP script generated a run-time error. So you should check the PHP error log.
One problem with AJAX is that it can be hard to debug a malfunctioning application. Here are a couple of hints:
Use a JSON validation tool if you have reason to suspect that the JSON data that you pass back and forth might be broken. Your source code editor of choice may have one, built-in or as a plugin. Otherwise you can use an online variant, for example JSONLint that I use myself. Just cut and past the data from the debugger to the validator.
Examine the PHP error log on the web server for errors and warnings generated by your PHP script(s):
- If you have shell access to the server, you can read the log file directly. The default path and name of this file can be very different depending on several factors, so I’ll just say that on my local server, running Ubuntu Server 14.04, and where I installed Apache and PHP via
apt-get, the default location of the log file is
/var/log/apache2/error.log. This log file is (and should be) protected so that normal users cannot even read it, meaning that you probably need to use
sudoto examine it. For example with:
Shell1sudo tail /var/log/apache2/error.log
- If you use a web hosting service, you might not have that option, but then there should be another way for you to read the log. This can work very differently between different service providers, but as an example, at GoDaddy.com, I can read the PHP log by logging in to my account, going to the cPanel page, and clicking on “Error logs” under the “Logs” heading.
Even if everything seems to work, it might still be a good idea to look at this error log from time to time, and check for warnings and non-critical error messages that may indicate a hidden problem.
$response_arr array in the example) with relevant information other than the requested data, you will have a nice tool for isolating any problems.
For example, I’m currently writing an application where the PHP script has to dynamically generate SQL statements for querying an Oracle database, based on the search parameters passed to it in the request. These SQL statements can become really complex, and it is easy to make mistakes (which I have done frequently). To help with debugging the problem, I would add the generated SQL code to the result object:
$result_arr["DEBUG_sql"] = $my_generated_sql_statement;