Debugging xajax

The best way to keep an eye on the requests/responses is using the Firebug (www.getfirebug.com) plugin for Firefox. The Firebug plugin has a XMLHttpRequest monitor showing all GET/POST request sent to the server, the request and response http headers as well as the server's response in plain text. Using FireBug you can see all necessary informations to find out what is wrong.

Sometimes it's neither the XHR request nor the server response that's causing troubles. A mistaken variablename or a typo in a MySQL query can be hard to point out, especially when you can't print/echo any variables directly inside your functions (remember printing/echoing any data or whitespaces breaks the XML response).
FirePHP (www.firephp.org), an extension for Firebug, is filling that hole. FirePHP consists of an extenion for Firefox and a PHP class with a small, but yet powerful API. You can dump all vars via the PHP class inside your php functions and the debug messages appear in the firebug console afterwards. The contents are being send via additional HTTP headers and therefore it doesn't interfere the xajax XML response.

Character encodings

The preferred character encoding for ajax applications of any kind is UTF-8. Since the XMLHttpRequest sends all data encoded in UTF8, regardless of the website's encoding, it's mostly the best choice to use UTF-8 right from the start.

You can however use any other encoding in xajax if cannot or refuse to work with UTF-8.

Code: php

 
$xajax->setCharEncoding('ISO-8859-1');
$xajax->setFlag("decodeUTF8Input",true);
 

The function setCharEncoding() instructs xajax to return the XML response in your desired encoding. The SetFlag() call forces xajax to automatically decode all incoming request data into the encoding you set before.

Regardless of your preferred charset encoding, you have to make sure that all your files containing contents are saved in that encoding. Furthermore, if you'r using a database like MySQL, you have to make sure that all your tables, fields and the even connection collation use the same encoding. Otherwhise it *will* break your XML response.

The Internet Explorer is very picky about encodings and refuses to parse any malformed XML, though the same functions may work fine in FireFox.

When you notice that the XHR itself works fine, but the browser doesn't display any special characters properly you have to check both the encoding sent by the server (http header) and the encoding set in the HTML meta tags. If either one of them is set to another encoding the browser won't display non-ASCII characters properly.

If you don't have access to your webserver config, you can set the http header encoding manually:

Code: php

 
header("Content-Type:text/html;charset:ISO-8859-1;");
 

Note, this applies for your HTML code, not for the xajax responses. If you have both xajax functions and the html code in the same file, put it below the $xajax->procesRequest() call. Otherwhise, it will break the response too! ;)

Whitespaces

Whitespaces can cause big troubles, but it's easy to avoid them. The easiest trick is, to not close the php tag. If you don't add the final "?>" in your PHP file(s) then the PHP parser will automatically insert a virtual one after the last character.
This affects all sorts of PHP applications that create anything fussier than HTML (GIF, PDF, etc). Leaving exterior whitespace is particularly bad form for include()d/require()d files. A typical consequence for HTML apps is being unable to send headers (including cookies). Also keep an eye out for your error reporting level and display_errors setting.

If you're desperate to hold onto your precious "?>" tag, just wrap your include()/require() in with the "ob_start(); ... ob_end_clean();" functions.