Категории
Подробнее о PSR-3. Интерфейс протоколирования
PSR - это рекомендации по оформлению кода на PHP. Я писал ранее вводную статью об этом. Я хочу подготовить ряд статей о каждом из принятых на данный момент стандартов и поскольку нужно будет приводить много кода, то для каждого из стандартов будет отдельная статья. Я думал всю информацию уместить в один пост с примерами, но, как следует изучив вопрос понял, что это получится громадная простыня текста, которую сложно будет воспринять. Эта статья будет посвящена стандарту PSR-3. Пока что проработано 5 стандартов:
PSR-3 – Интерфейс протоколирования
Данный документ описывает общий интерфейс библиотек протоколирования.
Основная цель данного документа – позволить библиотекам получать объект Psr\Log\LoggerInterface и использовать его простым и универсальным образом для реализации протоколирования. В случае, если некий фреймворк или CMS нуждается в расширенном функционале, МОЖНО расширять данный интерфейс, но СЛЕДУЕТ сохранять совместимость с описанными в данном документе правилами. Это позволит сторонним библиотекам, применяемым при разработке приложения, использовать централизованную систему протоколирования.
Слова «НЕОБХОДИМО» / «ДОЛЖНО» ("MUST"), «НЕДОПУСТИМО» ("MUST NOT"), «ТРЕБУЕТСЯ» ("REQUIRED"), «НУЖНО» ("SHALL"), «НЕ ПОЗВОЛЯЕТСЯ» ("SHALL NOT"), «СЛЕДУЕТ» ("SHOULD"), «НЕ СЛЕДУЕТ» ("SHOULD NOT"), «РЕКОМЕНДУЕТСЯ» ("RECOMMENDED"), «МОЖЕТ» / «ВОЗМОЖНО» ("MAY") и «НЕОБЯЗАТЕЛЬНО» ("OPTIONAL") в этом документе следует понимать так, как это описано в RFC 2119 (и его переводе).
Слово «разработчик» (implementor) в данном документе следует понимать как «автор, реализующий интерфейс LoggerInterface в неких библиотеке или фреймворке, связанных с протоколированием». Пользователи систем протоколирования упоминаются как просто «пользователи».
1. Спецификации
1.1 Основы
Интерфейс LoggerInterface предоставляет восемь методов протоколирования, соответствующих восьми уровням протоколирования, описанным в RFC 5424 (отладка (debug), информация (info), замечание (notice), предупреждение (warning), ошибка (error), критическая ошибка (critical), тревога (alert), авария (emergency)).
Девятый метод, «протокол» (log) принимает в качестве первого аргумента уровень протоколирования. Вызов этого метода с передачей константы одного из уровней протоколирования ДОЛЖЕН приводить к тому же результату, что и вызов соответствующего переданному уровню протоколирования специального метода.
Вызов этого метода с передачей уровня протоколирования, не описанного в данной спецификации, ДОЛЖЕН приводить к порождению исключения Psr\Log\InvalidArgumentException в случае, если конкретная реализация системы протоколирования не поддерживает переданный уровень протоколирования.
Пользователям НЕ СЛЕДУЕТ использовать собственные уровни протоколирования без полной уверенности в том, что конкретная реализация системы протоколирования их поддерживает.
1.2 Сообщения
- Каждый метод протоколирования должен принимать строку-сообщение или объект с методом __toString(). Разработчики МОГУТ использовать специальные обработчики переданных объектов, но если этого не сделано, объект ДОЛЖЕН быть приведён к строке.
- Строка-сообщение МОЖЕТ содержать плейсхолдеры, которые МОГУТ быть заменены на конкретные значения из массива context.
- Имена плейсхолдеров ДОЛЖНЫ совпадать со значениями ключей массива context.
- Плейсхолдеры ДОЛЖНЫ быть заключены в одиночные фигурные скобки, при этом НЕ ДОЛЖНО быть пробелов между фигурными скобками и именем плейсхолдера.
- Имена плейсхолдеров НУЖНО составлять только из символов A-Z, a-z, 0-9/span<, знак подчёркивания (_) и точка (.). Остальные символы зарезервированы для будущих изменений в спецификации плейсхолдеров.
- Разработчики МОГУТ реализовывать со значениями плейсхолдеров различные стратегии экранирования и преобразования при отображении протокола. Пользователям НЕ НУЖНО предварительно экранировать данные в значениях плейсхолдеров, т.к. заранее не известно, как и в каком контексте содержащаяся в них информация может быть использована.
Ниже для ознакомления представлен пример обработки плейсхолдеров.
$val) {
$replace['{' . $key . '}'] = $val;
}
// Подстановка значений в сообщение и возврат результата.
return strtr($message, $replace);
}
// Сообщение с плейсхолдером, имя которого обрамлено
// фигурными скобками.
$message = "User {username} created";
// Массив context с данными для замены плейсхолдера на
// итоговое значение.
$context = array('username' => 'bolivar');
// Результат: "User bolivar created"
echo interpolate($message, $context);
1.3 Контекст
- Каждый метод получает массив сопутствующих данных (context), содержащих дополнительную информацию, представление которой в виде строки не является оптимальным. На содержимое массива не налагается никаких ограничений. Разработчики ДОЛЖНЫ обрабатывать данные массива context максимально гибко. Переданные в массиве context данные НЕ ДОЛЖНЫ порождать исключений, вызывать сообщений об ошибках, предупреждений или замечаний от интерпретатора PHP.
- Если в массив context передан объект исключения, он ДОЛЖЕН находиться в элементе с ключом exception. Протоколирование исключений является распространённой практикой и позволяет разработчикам извлекать данные трассировки стека, если система протоколирования поддерживает такую функциональность. Разработчики ДОЛЖНЫ удостовериться, что в элементе с ключом exception на самом деле находится объект исключения, т.к. в реальности там МОЖЕТ оказаться что угодно.
1.4 Вспомогательные классы и интерфейсы
- Класс Psr\Log\AbstractLogger позволяет очень легко реализовать интерфейс LoggerInterface – достаточно создать свой класс-наследник и реализовать там метод log. Остальные восемь методов будут передавать сообщения и контекст в этот метод.
- Аналогично, использование Psr\Log\LoggerTrait требует всего лишь реализовать метод log. Однако в связи с тем, что примеси не могут реализовывать интерфейсы, вам всё равно придётся реализовать LoggerInterface.
- Класс Psr\Log\NullLogger, поставляемый с соответствующим интерфейсом, МОЖЕТ быть использован для реализации «записи протокола в пустоту», однако условное протоколирование может оказаться лучшим решением в случае, если создание контекстной информации является затратной операцией.
- Интерфейс Psr\Log\LoggerAwareInterface содержит только метод setLogger(LoggerInterface $logger) и может быть использован для автоматического связывания необходимых сущностей с системой протоколирования.
- Примесь Psr\Log\LoggerAwareTrait может быть легко использована для реализации соответствующего интерфейса. Она предоставляет доступ к $this->logger.
- Класс Psr\Log\LogLevel содержит константы восьми уровней протоколирования.
2. Пакет
Описанные интерфейсы и классы, равно как и соответствующие классы исключений и тестовые сценарии для проверки вашей реализации системы протоколирования предоставляются в составе пакета psr/log.
3. Интерфейс Psr\Log\LoggerInterface
4. Интерфейс Psr\Log\LoggerAwareInterface
5. Класс Psr\Log\LogLevel
Информация
Автор
webmancer
Нравится
0
Рейтинг
1
Не нравится
0
Голосов
1
Прочитали
1
Дата
2015-10-06 09:00:00
В избранном
0
Ваша реакция
Только авторизованные пользователи могут участвовать в рейтингах, делать заметки и добавлять в избранное.
На рекомендательном сервисе WEBmancer.Org только зарегистрированные пользователи могут комментировать и оставлять рецензии. Авторизованный пользователь так же может ставить отметки книгам, фильмам и другим постам. Вести учет прочитанных книг и просмотренных фильмов. Добавлять посты в избранное и иметь к ним быстрый доступ.