View Source

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{zone-template-instance:ZFPROP:Proposal Zone Template}
{composition-setup}

{zone-data:component-name}
Zend_Log_Writer_Firebug
{zone-data}

{zone-data:proposer-list}
[Christoph Dorn|mailto:christoph@christophdorn.com]
{zone-data}

{zone-data:liaison}
[~matthew]
{zone-data}

{zone-data:revision}
1.0 - 15 June 2008: Initial Draft.
1.1 - 27 June 2008: Revisions based on comments.
1.2 - 16 July 2008: Major revision based on feedback from Wil and Matthew
{zone-data}

{zone-data:overview}

{info:title=Status}
This component is now in the standard incubator with complete documentation and tests.
{info}

Zend_Log_Writer_Firebug is used to inject logging messages into the [Firebug|http://www.getfirebug.com/] Console from PHP. The component is a plugin for the Wildfire project. The goal of the Wildfire project is to develop standardized communication channels and a dynamic and scriptable remote plugin architecture. At this time the primary focus is to provide a system to allow PHP code to inject logging messages into the Firebug Console.

For the purpose of logging to Firebug a communication protocol has been developed that uses HTTP request and response headers to send data between the server and client components. It is great for logging intelligence data generated during script execution to the client browser without interfering with the page content. Debugging AJAX requests that require clean JSON and XML responses is possible with this approach.

{deck:id=Screenshots}
{card:label=Screenshots ->}
{card}
{card:label=Firebug Console logging}
!Sample1a.png!
{card}
{deck}

h3. Why Wildfire

Javascript is becoming a major force in client browsers and applications not only for enhancing web pages but also the browser and applications themselves. The Firefox browser is a great example of an application that can be extended by Javascript-based extensions. Up until now extensions installed on the client were fixed in their functionality and ability to interact with the loaded web age. That is about to change.

Wildfire will provide a standard for allowing server-side code to dynamically extend and enhance client extensions in a streamlined and secure fashion. Users will not need to install custom extensions for specific sites, but rather simply authorize a specific site to load dynamic extensions into the browser. The dynamically loaded extensions will reside in a sandbox with the same security policies as any other web page. In addition, the Wildfire client extension will provide an API to interact with the browser itself. This API is also extensible by plugins which are installed as any other browser extension.

The Wildfire concept has been proven by the [FirePHP|http://www.firephp.org] project. The Wildfire communication protocols and plugin system will be developed over time based on user demand.
{zone-data}

{zone-data:references}
* [Wildfire|http://www.wildfirehq.org/] - work in progress - will have more information soon
* [Firebug|http://www.getfirebug.com/]
* [FirePHP|http://www.firephp.org/]
* [symfony debug toolbar|http://www.symfony-project.org/book/1_0/16-Application-Management-Tools]
{zone-data}

{zone-data:requirements}
* This component *will not* be automatically initialized by default
* This component *will* send logging information to Firebug only if the developer requests it
* This component *will not* send any logging information in the response headers if the FirePHP extension is not installed on the client
* This component *will* provide a Zend_Log_Writer implementation
* This component *will* provide a facility to log Exceptions
* This component *will* provide a Zend_Controller_Plugin_Abstract implementation to flush debug data on request end but before page content is sent
* This component *will not* prevent cyclical exception handling should exceptions occur in the component. This *must* be handled by the developer.
* This component *will* make use of Zend_Json_Encoder to encode debug data
* This component *will* allow for mapping of all existing and custom Zend_Log priority levels to Firebug logging styles
* This component *will not* save any data using Zend_Cache or the filesystem.
{zone-data}

{zone-data:dependencies}
* Zend_Loader
* Zend_Log_Writer_Abstract
* Zend_Controller_Request_Abstract
* Zend_Controller_Response_Abstract
* Zend_Controller_Plugin_Abstract
* Zend_Json_Encoder
{zone-data}

{zone-data:operation}
h3. Overview
The idea is that the Zend_Log_Writer_Firebug component will provide the first transport to send debug information to a client in a non-destructive way. In this case the Firebug Console (via FirePHP).

Zend_Log_Writer_Firebug as it is implemented now provides a great way to aid in debugging Zend Framework applications on an ad-hock basis. This use-case will be expanded to a more comprehensive debugging framework that hooks into all Zend Framework components.

h3. Future
The future debugging/intelligence/insight system, possibly implemented by an enhanced Log Writer should collect data at all critical points within all components and provide facilities to enable and disable debug information on a component basis. The collected debug information may be persisted to files, logged or otherwise recorded as well as sent to the client via Zend_Log_Writer_Firebug.

A future version of Zend_Wildfire (the Firefox extension as well as the Zend components) will provide a debug toolbar to be displayed in the browser similar to the symfony debug toolbar. To achieve this we must first collect the mentioned debug information on a component basis.

All functionality beyond the current implementation should be part of new proposals that if applicable require certain additions to the Zend_Wildfire components.
{zone-data}

{zone-data:milestones}
* Milestone 1: \[DONE\] Reference implementation
* Milestone 2: \[DONE\] Reference implementation refined
* Milestone 3: \[DONE\] Working prototype checked into the incubator
* Milestone 4: \[DONE\] Unit tests exist, work, and are checked into SVN.
* Milestone 5: \[DONE\] Initial documentation exists.
{zone-data}

{zone-data:class-list}
* Zend_Log_Writer_Firebug
* Zend_Wildfire_Exception
* Zend_Wildfire_Plugin_FirePhp
* Zend_Wildfire_Plugin_Interface
* Zend_Wildfire_Channel_Interface
* Zend_Wildfire_Channel_HttpHeaders
* Zend_Wildfire_Protocol_JsonStream
{zone-data}

{zone-data:use-cases}
Typical use of the Zend_Log_Writer_Firebug component will be in conjunction with Zend_Controller_Front. In these use-cases initialize the component in your bootstrap file and use the logging calls in your models, views and controllers.
{code:php}
$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);
{code}

{deck:id=Use Cases}
{card:label=Ad-hock debug logging}
{code:php}
$logger->log('This is a log message!', Zend_Log::INFO);
{code}
{card}
{card:label=Table logging}
{code:php}
$writer->setPriorityStyle(8, 'TABLE');
$logger->addPriority('TABLE', 8);

$table = array('Summary line for the table',
array(
array('Column 1', 'Column 2'),
array('Row 1 c 1',' Row 1 c 2'),
array('Row 2 c 1',' Row 2 c 2')
)
);
$logger->table($table);
{code}
{card}
{card:label=Trace logging}
{code:php}
$writer->setPriorityStyle(8, 'TRACE');
$logger->addPriority('TRACE', 8);
$logger->trace('Trace to here');
{code}
{card}
{card:label=Exception logging}
{code:php}
try {
throw new Exception('Test Exception');
} catch(Exception $e) {
$logger->err($e);
}
{code}
{card}
{card:label=Error Controller}
{code:php}
class ErrorController extends Zend_Controller_Action
{
public function errorAction()
{
/*
* Make sure we don't log exceptions thrown during the exception logging.
* If we do we will create an infinite loop!
*/

try {

Zend_Registry::get('logger')->err($this->_getParam('error_handler')->exception);

} catch(Exception $e) {

/* TODO: You can log this exception somewhere or display it during development.
* DO NOT USE THE logger here as it will create an infinite loop!
*/

}
}
}
{code}
{card}
{deck}

You can also use Zend_Log_Writer_Firebug without Zend_Controller_Front.
{code:php}
$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);

$request = new Zend_Controller_Request_Http();
$response = new Zend_Controller_Response_Http();
$channel = Zend_Wildfire_Channel_HttpHeaders::getInstance();
$channel->setRequest($request);
$channel->setResponse($response);
/**
* Now you can make calls to the logger
*/

$logger->log('This is a log message!', Zend_Log::INFO);

/**
* Flush log data to browser
*/
$channel->flush();
$response->sendHeaders();
{code}

{zone-data}

{zone-data:skeletons}

{deck:id=Skeletons1}

{card:label=Zend_Log_Writer_Firebug}
{code:php}
class Zend_Log_Writer_Firebug extends Zend_Log_Writer_Abstract
{
protected $_priorityStyles = array(Zend_Log::EMERG => Zend_Wildfire_FirePHP::ERROR,
Zend_Log::ALERT => Zend_Wildfire_FirePHP::ERROR,
Zend_Log::CRIT => Zend_Wildfire_FirePHP::ERROR,
Zend_Log::ERR => Zend_Wildfire_FirePHP::ERROR,
Zend_Log::WARN => Zend_Wildfire_FirePHP::WARN,
Zend_Log::NOTICE => Zend_Wildfire_FirePHP::INFO,
Zend_Log::INFO => Zend_Wildfire_FirePHP::INFO,
Zend_Log::DEBUG => Zend_Wildfire_FirePHP::LOG);
protected $_defaultPriorityStyle = Zend_Wildfire_FirePHP::LOG;

public function setDefaultPriorityStyle($style);
public function setPriorityStyle($priority, $style);
public function setFormatter($formatter);
protected function _write($event);
}
{code}
{card}

{deck}
{zone-data}

{zone-template-instance}]]></ac:plain-text-body></ac:macro>