Как стать автором
Обновить

Комментарии 13

почему не приделали все это в виде обычного расширения/плагина/модуля или как там это называется в modx? В проекте на чем-то современном использовать это нет смысла т.к. уже существуют
http://phpdebugbar.com/
https://github.com/symfony/var-dumper
По самому коду — очень неряшливо написано, постоянные смешивания конструкций
	namespace Alpa\PhpDump;
	// the file for the autoloader will load when accessing the class.
	include_once __DIR__.'/../include_file_in_index.php';

и кучи закомментированных кусков кода
а также куски с дебаг-информацией
Ну и завязка на апач тоже не в плюс
Tracy легко внедряется и кастомизируется под любой проект
тоже хороший вариант. автору проще было бы интегрировать что-то из этого в modx чем писать с нуля то что он написал
Проект является не только для MODX. Я написал его для себя. Просто поделился. Будет неоднократный рефакторинг и code review как руки дойдут. Но пока что работает, не хочу трогать и прокачивать.
Почитал доку Tracy. Там при анализе объектов и массивов, есть ограничение по глубине вложений. Я в свое время встретился с таким же ограничением в PhpConsole и отсутствием детализированных данных. Это меня и побудило написать собственную реализацию по анализу массивов и объектов. В моем случае можно анализировать толстые объекты и массивы с неограниченной вложенностью. Конечно может возникнуть ошибка memory size, но она возникнет при очень жирных объектах. Пока это единственное ограничение. По степени необходимости, по этой части будет рефакторинг.
С объектом $modx со всеми его вложениями справляется в легкую. Также петли, не повлияют на анализ. Они вычисляются и исключаются.
А рекурсивная детализация объекта, не однократно спасала. Можно посмотреть как детализирует состояние объекта. через вызов \deb::dump($obj); Возможно есть другие компоненты которые я не до оценил. Но на меня нашло вдохновение написать что то собственное.
— Tracy это панель сводной информации куда удобно выводить вкладки (какие события были запущены и с какими параметрами) / какие чанки / сниппеты отработаны / под каким юзером работаете и т.п.
— Если говорить конкретно за дамп, то раз нет доступа к xDebug можно воспользоваться var-dumper как уже сказали выше. В Tracy он действительно немного убогий

По большому счету вы просто попытались совместить 2 инструмента в 1. Чтож, это ваше право…
Причин несколько.
Реализация по большому счету не должна интегрироваться в фреймворки или CMS, а выполняться параллельно. Один раз установил на dev машине, потом где необходим анализ, в том проекте и подключаешь. Изначально пользовался с помощью плагина. Но почему отказался от такой реализации*? А до инициализации события MODXInit сколько строчек кода пропустим*? Может необходимо отладить код в самом MODX? К примеру, в один момент необходимо было провести анализ Index.php, чтобы внести свою корректировку для мультисайтовости. А если код падает до инициализации компонента, то вычислить проблему вообще не возможно. Если PHPDump будет запускать ранее до запуска основного сценария, то проблемы можно отслеживать.


Для запуска PhpDump на CMS MODX Есть несколько решений.

Вариант с плагином на событиях OnInitCulture или OnMODXInit был бы более предпочтителен
По-моему, clockwork на порядок удобнее и полезнее будет. Туда не только дампы можно впихнуть, но и кучу другой сопутствующей информации. А т.к. это ещё и расширение для браузера, то можно и в API использовать, где не должно быть другой информации, вроде скриптов.
Смотря на ваши куски кода, кровь из глаз идёт…
Когда сам смотрю, тоже кровь идет. Но сначала реализуешь идею, перекладывая мысли в код, потом ее приводишь в порядок. Но пока собираюсь духом привести все в порядок.
Никак не могу понять вечное массовое игнорирование Xdebug'а.
Согласен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории