This allows you to inspect native PHP values and objects inside the FireBug console.

Because this adapter interacts directly with the `Response` object, some additional code is
required to use it. The simplest way to achieve this is to add a filter to the `Dispatcher`. For
example, the following can be placed in a bootstrap file:

{{{
use lithium\action\Dispatcher;
use lithium\analysis\Logger;

Logger::config(array(
	'default' => array('adapter' => 'FirePhp')
));

Dispatcher::applyFilter('_call', function($self, $params, $chain) {
	if (isset($params['callable']->response)) {
		Logger::adapter('default')->bind($params['callable']->response);
	}
	return $chain->next($self, $params, $chain);
});
}}}

This will cause the message and other debug settings added to the header of the
response, where FirePHP is able to locate and print it accordingly. As this adapter
implements the protocol specification directly, you don't need another vendor library to
use it.

Now, in you can use the logger in your application code (like controllers, views and models).

{{{
class PagesController extends \lithium\action\Controller {
	public function view() {
		//...
		Logger::error("Something bad happened!");
		//...
	}
}
}}}

Because this adapter also has a queue implemented, it is possible to log messages even when the
`Response` object is not yet generated. When it gets generated (and bound), all queued messages
get flushed instantly.

Because FirePHP is not a conventional logging destination like a file or a database, you can
pass everything (except resources) to the logger and inspect it further in FirePHP. In fact,
every message that is passed will be encoded via `json_encode()`, so check out this built-in
method for more information on how your message will be encoded.

{{{
Logger::debug(array('debug' => 'me));
Logger::debug(new \lithium\action\Response());
}}}