19.3. Генерация системного журнала в XML+WDDX,

Теперь в качестве иллюстрации рассмотрим практический пример работы подсистемы обработки ошибок в РНР. Мы создадим собственную функцию обработчика ошибок, которая будет генерировать журнал, представленный в модном XML-формате, а также отправлять письмо администратору узла при обнаружении критических ошибок. Поскольку нам придется иметь дело с массивами, для их помещения в журнал мы воспользуемся WDDX.

Возможно, пример, приведенный в листинге 19.1, покажется вам достаточно длинным, но, поверьте, дело того стоит.

Давайте рассмотрим работу этой программы подробнее. Состоит она из двух основных частей: формирование журнала и его последующий просмотр. Поскольку пользователь nobody, от имени которого обычно запускаются PHP-программы на сервере Apache, не имеет особых прав на работу с файловой системой, для размещения системного журнала мы будем использовать каталог tmp.

Обратите внимание на команду unlinks самом начале программы. Дело в том, что XML-документ может содержать только один элемент верхнего уровня, а команда еrror_l og осуществляет дописывание в конец существующего файла. Поэтому если вы не будете создавать системный журнал заново, то выполнить программу больше одного раза просто не сможете: анализатор XML аварийно завершит работу при обнаружении второго документа верхнего уровня.

После этого мы создаем новый файл журнала и помещаем в него открывающий тег <ERRORLOG>. Затем устанавливаем свой собственный обработчик ошибочных ситуаций, в задачу которого входит сформировать запись в XML-формате, которая будет записана в журнал. До тех пор, пока структура записи определена достаточно жестко:

никакой необходимости в использовании WDDX не возникает. Эти данные без особых проблем считываются и разбираются анализатором XML точно так же, как и в разделе 18.4. Но в некоторых ситуациях нам бы хотелось, чтобы в системный журнал наряду с текстом сообщения об ошибках помещались также значения переменных, действующих на момент возникновения этой ошибки. Стандартный механизм обработки ошибочных ситуаций PHP-машиной этой информации нам не дает. Но мы сможем справиться с этой проблемой и самостоятельно.

В результате мы создаем собственное поле <VARTRACE>, внутри которого поместим WDDX-пакет, составленный из списка локальных переменных (аргумент $vars), определенных в процедуре в момент обнаружения ошибки. Понятно, что и имена, и значения этих переменных будут меняться от функции к функции и от ошибки к ошибке. Но для нас важно другое: PHP-машина автоматически формирует WDDX-пакет и затем помещает его в выходной файл. В результате мы полу- чаем запись вида:

Как видите, WDDX-пакет органично помещается внутрь XML-доку мента, что одновременно и хорошо, и плохо. Хорошо с той точки зрения, что позволяет аккуратно закруглить4 главу, заявив, что анализ XML был рассмотрен выше и использование функции wddx_desrialize () автоматически решит все ваши проблемы. А плохо потому, что это на самом деле не так и анализ XML-документа со встроенными пакетами WDDX реализуется не столь прямолинейно, как нам хотелось бы.

Собственно говоря, именно поэтому в рассматриваемый нами пример я включил и новую версию анализатора, ориентированную именно на обработку сгенерированного нами файла.

Проблема заключается в том, что теги WDDX ничем, по сути, не отличаются от тегов XML, а следовательно, они будут автоматически обрабатываться обработчиками событий. Но так ли это здорово на самом деле? Ведь чтобы разобрать XML-документ с вложенными WDDX-пакетами вам потребуется фактически самостоятельно реализовать обработку тегов WDDX внутри анализатора. При этом вам не удастся «просто так» получить исходный код пакета, который можно одним вызовом функции превратить в структуру данных, аналогичную той, которая использовалась для синтеза пакета. Но разве мы за это боролись?

Единственное достаточно компактное решение состоит в том, что мы в процессе анализа восстанавливаем текст WDDX-пакета со всеми его атрибутами, а после завершения его сборки (о чем нам сигнализирует тег </VARTRACE>) мы разбираем полученный нами пакет функцией wddx_deserialize и только потом извлекаем из нее список переменных и их значения.

Результаты выполнения этой программы приведены на рис. 19.1. Как видите, нам удалось реализовать механизм отладки программы, который позволяет старым добрым методом контрольной печати вскрыть практически любые ошибки времени исполнения программ. Но гораздо важнее, что теперь в вашем распоряжении имеется механизм, позволяющий полностью реализовать межзадачный обмен данными — как из приложения на РНР, так и из внешнего мира.