Дебаг в Zend Framework с использованием FirePHP // PHP

Есть одно правило – не показывать заказчику debug информацию, для этой цели обычно существует две конфигурации, но если заказчик очень любопытен, либо Вам, из эстетических побуждений, хочется скрыть килобайты дебаг информации? В этих благих намерениях нам поможет FirePHP.

Для тех кто не знает – FirePHP – это расширение плагина FireBug для Mozilla Firefox

Для этой цели нам понадобиться в Вашем Zend Framewrok’овском проекте немного изменить bootsrap.php и добавить пару файлов в library. Начну с простого – изменяем bootstrap:

// этот кусок кода вставляем после подгрузки конфиг-файла
{
    // переменная из конфига, которая отвечает за вывод debug информации
    if ($config->application->debug) {
	/* Turn on all errors and STRICT notices */ 
    	error_reporting(E_ALL | E_STRICT);
    	ini_set('display_errors', 1);
    	ini_set('display_startup_errors', 1);

        require_once 'Core/Debug.php';    // подключаем класс Core_Debug - что он делает читаем далее
        Core_Debug::setEnabled(true);
        Core_Debug::getGenerateTime('Begin');
    } else {    
    	/* Turn off all errors */ 
    	error_reporting(0);
    	ini_set('display_errors', 0);
    	ini_set('display_startup_errors', 0);
    }
}

// это включение после инициализации DB адаптера
{
    // как-то так его инитим
    $dbAdapter = Zend_Db::factory($config->database);

    // подключаем профайлер
    if ($config->application->debug) {
        require_once 'Core/Db/Profiler.php';    // подключаем Core_Db_Profiler - это не совсем стандартный профайлер для БД
        $profiler = new Core_Db_Profiler('Profiler');
        $profiler->setEnabled(true);

        $dbAdapter->setProfiler($profiler);
    }
}

Теперь перейдем к вкусному…

DB_Profiler

Core_Db_Profiler (хотя по всем правилам он должен называться Core_Db_Profiler_Firebug) это класс для отладки работы приложения с БД (см. Zend DB Profiler), наследуется он от Zend_Db_Profiler_Firebug, содержит лишь одно изменение – добавлен backtrace, т.к. очень полезно знать откуда был осуществлен тот или иной запрос к базе данных.

Выглядит это следующим образом (кликабельно):

Debug

Класс Core_Debug наследуется от Zend_Debug и расширяет его функционал для работы с FirePHP, добавлена функция debug, которая выводит информацию о переменной (-ных) в консоль Fire Bug’а, приведу пример кода PHP:

        $a = $b = $c = array(123, 456, 789);
        Core_Debug::debug($a); // выводим одну переменную
        Core_Debug::debug($a, $b, $c); // выводим несколько переменных

Результат можно увидеть в консоли:

Последней строчкой выводится backtrace – дабы не было проблем с поиском строки где Вы вызываете debug. Но есть с данным способом дебага одна проблема – если слишком много данных, то браузер просто подвиснет, пытаясь выполнить JavaScript.

Есть еще одна полезная функция в классе Core_Debug – зовется она getGenerateTime – именно ее мы вызвали сразу после подключения Core_Debug – основная задача данной функции – оставлять временные метки по коду, т.е. вызываем метод первый раз – время вызова сохранилось, вызываем второй – сохраняем (выводим) разницу между предыдущим и первым вызовом. Приведу следующий пример, у меня в коде стоит три вызова:

// сразу после подключения Core_Debug
require_once 'Core/Debug.php';
Core_Debug::setEnabled(true);
Core_Debug::getGenerateTime('Begin');
/* ... */
// Index Action в Index Controller
Core_Debug::getGenerateTime('IndexAction');
/* ... */
// перед диспатчем
Core_Debug::getGenerateTime('Before Dispatch');
Zend_Controller_Front::getInstance()->dispatch();

Результатом опять станет консоль FireBug:

Где:

• Time (sec) – время от предыдущей “зарубки”
• Total (sec) – время от первой “зарубки”
• Memory (Kb) – кол-во памяти съеденной от предыдущей “зарубки”
• Total (Kb) – кол-во памяти съеденной за все время

Данные классы Вы можете скачать по следующей ссылке:

Download (2.5 Kb) FirePHP Debug

Ссылки по теме:

• FirePHP and Zend Framework 1.6 (перевод)

P.S. Спасибо Baziak’у за идею…