To start with, I just love FirePHP. This extension extends Firebug itself and allows PHP to show messages in the console.

FirePHP use special headers to send required information, so browses without FirePHP doesn’t feel any difference, but others can easily extract information. It doesn’t mean that DB profiling information should be visible in production server, but it definitely helps in development stages. If you look at normal website’s headers you would see something like this:

HTTP/1.x 200 OK
Date: Thu, 12 Mar 2009 14:29:29 GMT
Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.1 ...
X-powered-by: PHP/5.2.6-2ubuntu4.1
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

where FirePHP modifies it to:

HTTP/1.x 200 OK
Date: Thu, 12 Mar 2009 14:28:39 GMT
Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.1 ...
X-powered-by: PHP/5.2.6-2ubuntu4.1
X-Wf-Protocol-1: http://meta.wildfirehq.org/Protocol/JsonStream/0.2
X-Wf-1-Structure-1: http://meta.firephp.org/Wildfire/Structure/FirePHP/FirebugConsole/0.1
X-Wf-1-Plugin-1: http://meta.firephp.org/Wildfire/Plugin/ZendFramework/FirePHP/1.6.2
X-Wf-1-1-1-1: 56|[{"Type":"INFO","File":"","Line":""},"This is a debug!"]|
X-Wf-1-1-1-2: 58|[{"Type":"ERROR","File":"","Line":""},"This is an error!"]|
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

FirePHP website has libraries for sending these headers, but since I was trying it when using Zend Framework, I chose Zend_Log_Writer_Firebug module. It works as writer interface for Zend_Log and since Zend_Log is (or should be) used for all logging in ZF, you can get very nice access to all information (execution time, queries, warnings, etc.) from browser. For example, to send something with Zend Framework, code would look like this:

// Place this in your bootstrap
$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);
 
// Use this in your model, view and controller files
$logger->log('This is a log message!', Zend_Log::INFO);

Simple and clean (it won’t work if Zend_Controller_Front is not used, look at manual).

Logging to files still should be used for information which will be required for further analysis, eg. payment gateway errors, but such information as execution time works perfectly in FirePHP. Users doesn’t care how fast page was rendered, but developers sometimes needs this information and in my opinion, using FirePHP sounds most reasonable. Have you tried it?

Let’s say we have these variables, which we want to pass to JavaScript:

$array = array(
	'status' => 'OK',
	'message' => 'My status message',
	'additional' => array(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
);

From all available formats XML and JSON can be chosen as two absolutely different formats, since HTML is related to XML, JSONP to JSON. Let XML be our first choice. First, you need to encode this data in XML format, here ArrayToXML class can be used. Using given class, output can be generated by:

echo ArrayToXML::toXml($array);

Quite straightforward, but if you know how XML structured, you can image that output is “huge”:

<?xml version="1.0" encoding="utf-8"?>
<data><status>OK</status><message>My status message</message>
<additional>
<unknownNode>1</unknownNode><unknownNode>2</unknownNode>
<unknownNode>3</unknownNode><unknownNode>4</unknownNode>
<unknownNode>5</unknownNode><unknownNode>6</unknownNode>
<unknownNode>7</unknownNode><unknownNode>8</unknownNode>
<unknownNode>9</unknownNode><unknownNode>10</unknownNode>
</additional></data>

XML result’s mark-up is probably bigger than data itself – not very good when response should arrive as soon as possible. Now let’s compare it to JSON. PHP has native JSON support, so everything can be done with one function: json_encode. It is used like this:

echo json_encode($array);

Neither harder, nor easier to use than ArrayToXML. Main strength of JSON is output size:

{"status":"OK",
"message":"My status message",
"additional":[1,2,3,4,5,6,7,8,9,10]}

Thats it. For this example, size of outputs is different, but still so small, that speed increase would be unnoticeable. However, with bigger data sizes output size will start to matter. XML format, in my belief, is simply not the best in storing data efficiently, but still I use it for XML-RPC or SOAP.

jQuery (probably other libraries also) transforms returned string into object in background (it also does it safe, don’t evals() blindfolded) – response data can be used immediately. I haven’t checked, but transforming XML into object should be remarkably slower. You just need to make sure to specify correct response format and jQuery will do all the work for you:

$(document).ready(function() {
	$.get(
		'server.php',
		{param : "value"},
		function (data)
		{
			// data is now object
			// data.status, data.message,
			// data.additional.0-10 is available
		},
		"json" //!!!
	);
});

I used to use XML or even HTML for AJAX communications, but as soon as I discovered JSON, I absolutely forgot about all previous methods. In my opinion, JSON should be used as a default choice. Not only future browsers will have native JSON support, but it’s very easy to use even now. Both server-side app’s and jQuery support for JSON is very good (and fast).