Yii2 получить код ошибки

Yii2: Обработка ошибок

Обработка ошибок в Yii 2

Обработчик ошибок включен в Yii 2 по умолчанию. Отключить его можно добавив следующий код в стартовый скрипт приложения web/index. php:

Конфигурация по умолчанию

В шаблонах приложений Yii 2 basic и advanced обработчик ошибок подключен как компонент приложения errorHandler. Рассмотрим примеры конфигурации:

  • приложение basic: config/web. php;
  • приложение advanced: индивидуальные настройки для каждого из приложений frontend/config/main. php и backend/config/main. php.

Минимальная конфигурация обработчика ошибок использует site/error для отображения ошибок и исключений.

В данном случае нет необходимости в явном создании действия actionError в контроллере SiteController. Если заглянуть в файл SiteController. php, можно увидеть, что там использовано встроенное действие yii\web\ErrorAction, которое отображает информацию через представление views/site/error. php.

Настройка представления и шаблона

Возьмем за основу вышеописанную стандартную конфигурацию.

Представление описывается свойством view класса yii\web\ErrorAction:

В тоже время, шаблон для вывода сообщений об ошибках, можно изменить двумя способами:

1. Явно указав нужный шаблон в файле представления:

2. Указать шаблон в методе beforeAction() класса SiteController:

Свой обработчик ошибок

При необходимости, возможно создание своего метода для обработки ошибок. Например, создадим действие site/fault в контроллере SiteController:

И подключим его в конфигурационном файле:

Готово. Теперь все ошибки будут обрабатываться новым методом actionFault() контроллера SiteController.

Final product imageWhat You’ll Be Creating

Если вы спрашиваете «Что такое Yii?», ознакомьтесь с моим предыдущим учебным пособием: Введение в Yii Framework, в котором рассматриваются преимущества Yii и которое включает обзор нового в Yii 2.0, выпущенного в октябре 2014 года.

В этом курсе Программирование с Yii2 я направляю читателей на использование недавно обновленного Yii2 Framework для PHP. В этом уроке я собираюсь познакомить вас с валидаторами Yii2. Валидаторы упрощают код, необходимый для проверки ввода, то есть проверяют соответствие или несоответствие ввода данных, как правило, от пользователей через веб-формы.

В этих примерах мы продолжим использование кодовой базы приложения Hello, которую мы использовали в прошлых уроках. Используйте ссылки GitHub на этой странице, чтобы получить код.

Просто напоминание, я участвую в ниже выведенных комментариях. Меня особенно интересует, если у вас есть дополнительные идеи или вы хотите предложить темы для будущих учебников. Вы также можете связаться со мной @reifman в Twitter.

Что такое Валидатор?

Если вы являетесь веб-разработчиком, вы, вероятно, знаете, что пользователю нельзя доверять. Например, пользователи могут использовать методы SQL-инъекций, чтобы попытаться запустить запросы, которые изменяют или раскрывают пароли. Кто-то однажды запустил SQL-инъекцию против установки PHPList с открытым исходным кодом и смог открыть один из моих паролей (PHPList сохранял их в виде обычного текста). Чаще всего вы просто хотите убедиться, что данные, которые пользователи предоставляют, соответствуют типам, формам и диапазонам вашего приложения.

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

Валидации — еще одна причина, по которой я считаю, что всегда имеет смысл создавать приложения на веб-фреймворках, таких как Yii, а не на ванильном PHP.

В предыдущих эпизодах мы также много говорили о генераторе кода Yii — Gii. Одним из преимуществ Gii является то, что он напишет соответствующие правила проверки для ваших моделей на основе определений типа SQL в таблице. Это большая экономия времени.

Какие проверки поддерживает Yii?

Вот список встроенных валидаторов Yii и ссылки на документацию:

  • BooleanValidator. Обеспечивает, что значение — true или false.
  • CaptchaValidator. Проверяет поле проверки формы CAPTCHA.
  • CompareValidator. Сравнивает два значения из формы или константы, например, x должно быть меньше 99.
  • DateValidator. Обеспечивает, что значение — это дата.
  • DefaultValueValidator. Не настоящий валидатор. Устанавливает значения по умолчанию для пустых полей.
  • NumberValidator. Обеспечивает, что значение является числовым, например, integer или float.
  • EmailValidator. Обеспечивает, что значение является действительным адресом электронной почты.
  • ExistValidator. Обеспечивает, что значение существует в другой таблице.
  • FileValidator. Обеспечивает наличие загруженного файла.
  • FilterValidator. Не настоящий валидатор. Выполняет преобразование по предоставленному значению.
  • ImageValidator. Проверяет изображение и свойства изображения.
  • RangeValidator. Обеспечивает, чтобы значение находилось в списке значений.
  • RegularExpressionValidator. Выполняет проверку с условием, определенным регулярным выражением.
  • RequiredValidator. Обеспечивает наличие значения.
  • SafeValidator. Не настоящий валидатор. Позволяет массивное присвоение отправленной веб-формы для включения атрибута. например $model->attributes = $_POST[‘Comment’];
  • StringValidator. Обеспечивает, что значение — строка.
  • UniqueValidator. Обеспечивает уникальное значение в таблице, например адрес электронной почты.
  • UrlValidator. Обеспечивает, что значение в формате URL, например, https://yourdomain. com

Как работает валидация Yii

Вот как Yii описывает поток проверки. Как правило, вы можете использовать сценарий по умолчанию и не нужно создавать свои собственные. Обычно вам нужно полагаться на Gii, чтобы генерировать правила или писать свои собственные.

Когда вызывается метод validate() , он делает следующие шаги для выполнения проверки:

  1. Определяет, какие атрибуты должны быть проверены путем получения списка атрибутов из yii\base\Model::scenarios() с использованием текущего сценария. Эти атрибуты называются активными атрибутами.
  2. Определяет, какие правила проверки следует использовать, получив список правил из yii\base\Model::rules(), используя текущий сценарий. Эти правила называются активными правилами.
  3. Использует каждое активное правило для проверки каждого активного атрибута, связанного с этим правилом. Правила проверки проверяются в том порядке, в котором они перечислены.

Согласно вышеуказанным шагам проверки атрибут будет проверяться, если и только если он является активным атрибутом, объявленным в scenarios() и связан с одним или несколькими активными правилами, объявленными в rules() .

Пример правил проверки модели

Вот как может выглядеть набор правил проверки модели. Я взял их из приложения Планировщик встреч, модель Place:

По мере дальнейшего использования наших собственных примеров валидации вы узнаете, что представляет собой каждое из приведенных выше определений.

Пример отображения ошибок

Существует несколько способов доступа к ошибкам, возвращаемым валидацией.

Вот пример получения массива ошибок в контроллере:

И вот пример использования функции Yii errorSummary в ActiveForms:

Вот как это выглядит:

Using Yii errorSummary to display form errors

Расширенная проверка

В последующих эпизодах я также приведу примеры использования расширенных функций проверки:

  • Определение сценариев для выборочного применения правил для определенных ситуаций
  • События проверки для переопределения проверки или выполнения определенных функций до и/или после проверки
  • Условная проверка для выполнения правила валидации только в том случае, если конкретное событие истинно
  • Ad Hoc validation — для использования правил валидации независимо от отправки формы
  • Пользовательские валидаторы — для создания важных валидаций за пределами того, что Yii предлагает из коробки
  • Проверка на стороне клиента, чтобы использовать встроенную Yii ActiveForm проверку JavaScript, без необходимости обновления страницы.
  • Проверка AJAX для проверки подлинности AJAX на стороне сервера для расширения возможностей проверки JavaScript на стороне клиента

Теперь давайте начнем с примеров различных встроенных валидаторов.

Базовые валидаторы полей

Давайте посмотрим на некоторые из основных инструментов проверки поля, которые полезны для повседневной реализации.

Подготовка модели с использованием миграции и Gii

Как мы уже делали в ранних эпизодах этого курса, я собираюсь создать миграцию:

Я создам Sample модель, чтобы создать примерную таблицу и проверки с помощью Gii. Вот код миграции:

Затем мы выполним миграцию:

Далее мы будем использовать генератор кода Yii для построения модели:

Validation Yiis Gii Model Generator

А затем CRUD файлы:

Validation Yiis Gii CRUD Generator

Gii генерирует эти правила проверки образца:

Теперь давайте использовать их для работы и прохождения некоторых основных валидаторов.

Required Validator

RequiredValidator гарантирует наличие значения. Вы можете увидеть это выше для полей: rank, censorship и occurred.

Перейдите в форму создания Sample, сгенерированную Gii, например, https://localhost:8888/hello/sample/create. При проверке Yii ActiveForm на клиенте JavaScript будет отображать сообщение об ошибке даже при нажатии на одно из этих полей.

Validators Required With JavaScript Client Side Validation

Safe Validator

SafeValidator не является истинным валидатором. Он позволяет массовое присвоение переданной веб-формы для включения атрибута, например, $model->attributes = $_POST[‘Comment’]. Или, в созданном Gii SampleController, вы можете увидеть этот код:

Без безопасного правила в Sample модели (или другого правила) указанное значение не будет присвоено атрибутам модели. Это уменьшает вероятность наличия дополнительного вектора атаки без преднамеренного кода.

Default Value Validator

DefaultValueValidator не является истинным валидатором. Он устанавливает значения по умолчанию для пустых полей.

Давайте изменим правило для occurred , чтобы установить значение даты по умолчанию с использованием текущей даты. Мы также удалим Required валидатор, чтобы позволить Default валидатору заполнить значение.

Когда мы создаем новый Sample и оставляем пустое поле occurred , вы можете увидеть, что результирующее представление включает текущую дату, заполненную валидатором значений по умолчанию.

Validators Default Value

Фильтры

FilterValidator также не является истинным валидатором. Он выполняет преобразование по предоставленному значению. Чаще всего вы можете использовать его, чтобы обрезать пробелы с концов строки.

FilterValidators определяются с помощью встроенных функций обратного вызова, таких как эта пользовательская функция проверки:

Поскольку trim — это функция PHP, мы можем просто объявить наше правило валидации строкой:

Если вы отправляете форму с начальными или конечными пробелами в поле thought, FilterValidator удалит их.

Теперь давайте посмотрим на некоторые встроенные валидаторы типов.

Валидаторы типов

Валидаторы типов гарантируют соответствие пользовательских данных определенным типам, часто тем, которые указаны в таблице базы данных. Gii автоматически сгенерирует их.

String Validator и Number Validator

StringValidator гарантирует, что значение является строкой. NumberValidator гарантирует, что значение является числовым, например, integer или float.

Ниже приведены примеры правил:

Я также временно удаляю Required валидатор, чтобы посмотреть, как работают строковые и числовые проверки.

Вот как выглядят сообщения об ошибках проверки:

Validators Number and String

Goodness со значением high выдает ошибку, потому что это не число, а rank со значением 27 проходит проверку. Censorship пуста (NULL), поэтому не выполняется проверка строки.

Boolean Validator

BooleanValidator обеспечивает значение true или false. Вы можете определить значения для true и false. Значение по умолчанию — целое число 0 или 1. Этот валидатор может быть более полезным, когда поле используется с выпадающим списком, например, Да / Нет.

Вот как я определил свое правило для Boolean:

Вот сообщение об ошибке Boolean валидатора:

Validators Boolean

Date Validator

DateValidator гарантирует, что значение является правильно отформатированной датой, которую можно настроить с помощью атрибута format. С Yii ActiveForm в настоящее время это проверка на стороне сервера. Поэтому я также добавил требуемое правило для поля Occurred.

Вот мои определения правил с валидатором даты для поля Occused:

Вот как это выглядит, когда мы отправляем форму:

Validators Date

Что дальше?

Следите за предстоящими уроками в моем курсе Программирование с Yii2, так как я продолжаю погружаться в разные аспекты структуры. В следующих двух эпизодах я проведу вас через оставшиеся валидаторы и покажу вам, как создавать продвинутые расширения для системы проверки Yii.

Вы также можете ознакомиться с моим курсом Построение стартапа с помощью PHP, в которой используется расширенный шаблон Yii2, когда я создаю реальное приложение.

Я приветствую пожелания по темам. Вы можете опубликовать их в комментариях ниже, твитнуть @reifman на Twitter или отправить мне по электронной почте на моем веб-сайте Lookahead Consulting.

Если вы хотите узнать, когда выйдет следующий урок по Yii2, проверьте мою страницу инструктора Tuts+. Она всегда включает все мои опубликованные статьи.

Рекомендации по работе с Yii 2

В данном разделе опубликована информация, которая призвана решить спорные вопросы и определить порядок действий при их возникновении. Группой разработчиков мы собрали наиболее полный список рекомендаций, который поможет вам в создании новых модулей и приложений на Yii

Бизнес-логика

    Модели ActiveRecord должны описывать структуру данных таблиц в базе данных;

Бизнес-логике не место в ActiveRecord, контроллере и тем более в представлении. Размещать бизнес-логику необходимо в отдельных классах с говорящими названиями “СущностьДействие”. В результате получаются “худые” контроллер и ActiveRecord. Данный подход повышает читабельность проекта в разы, а также позволяет производить тестирование бизнес-логики.

Миграции в базе данных

  1. Категорически запрещено вносить изменения в структуру базы данных, а также добавлять/изменять/удалять данные в таблицах auth_item и auth_item_child в обход миграций. Все обновления в БД осуществляются только посредством оформления миграции.
    1. Все изменения данных, которые необходимо произвести единожды у всех участников проекта, необходимо реализовывать через миграции;
    2. Если изменения данных в БД необходимо производить с некой периодичностью, следует вынести такие изменения в консольное приложение.
      На практике встречаются случаи, когда разработчик размещает функционал, который более подходит для консольного приложения либо для миграций, в контроллер веб приложения, что недопустимо.

    Если в проекте используется СУБД MySQL для использования внешних ключей (Foreign keys) и транзакций, в качестве системы хранения данных (Storage engine) должна быть выбрана InnoDB. При создании таблицы в БД необходимо использовать следующую конструкцию:

    Структура базы данных

    1. Наименование таблиц и столбцов в БД.
      1. Необходимо убедиться в том, что имя уникально и его нет в списке зарезервированных ключевых слов ANSI SQL (92, 99 and 2003), MySQL версий с 3, PostgreSQL 8.1, MS SQL Server 2000, MS ODBC и Oracle 10.2.
      2. Названия таблиц должны быть в единственном числе. Исключением являются слова в английском языке, у которых нет формы единственного числа (например: “news”).
      3. В именах необходимо использовать только буквы, цифры и символ подчеркивания.
      4. Необходимо избегать нескольких подряд идущих символов подчеркивания.
      1. Не стоит забывать об индексах уникальности (UNIQUE INDEX) для того, чтобы избежать переполнение таблицы дубликатами.
      2. Если по определенному полю очень часто происходит выборка, ему необходимо добавить индекс (INDEX).
      3. Если запрос содержит много запросов JOIN, вам необходимо убедиться, что столбцы, к которым вы присоединяетесь, индексируются в обеих таблицах. Это влияет на то, как MySQL внутренне оптимизирует операцию соединения.

      Кеширование и переиспользование данных

      1. Кэшировать нужно данные, которые медленно генерируются и часто запрашиваются.
      2. Помимо внешнего кэширования данных (в файловом хранилище, Memcached, и т. д), во многих случаях необходимо кэшировать промежуточные результаты выполнения некоторых операций в рамках жизненного цикла приложения. В качестве:
        1. переменных;
        2. синглтон-классов;
        3. статических свойств класса;
        4. свойств компонентов Yii.

        Представления

        1. Название представления стоит начинать с символа нижнего подчеркивания “_” в случае, если представление рендерится без layout. Например:
          1. _header;
          2. _footer.

          Рекомендации по оформление кода в приложениях Yii 2

          Общие положения

          1. Имена методов, свойств и переменных должны быть объявлены с использованием т. н. «camelCase» (первое слово пишется в нижнем регистре, далее каждое слово начинается с большой буквы, а между словами нет разделителей).
            Данный пункт не имеет никакого отношения к виртуальным атрибутам ActiveRecord.
          2. Открывающая фигурная скобка в определении класса или метода должна располагаться на новой строке, а закрывающая фигурная скобка должна располагаться на следующей строке после тела класса/метода.
          3. Одиночный знак подчеркивания в начале имени свойства или метода не следует использовать как признак защищенной (protected) или приватной (private) области видимости.
          4. Открывающая фигурная скобка в управляющих конструкциях должна располагаться в той же строке, что и сама конструкция, а закрывающая фигурная скобка должна располагаться на следующей строке после тела конструкции.
            p
          5. Пустые строки могут быть добавлены в код для повышения удобочитаемости и разделения блоков кода.
          6. В одной строке не должно быть более одного выражения.

          Классы

          1. Каждый класс должен располагаться в отдельном файле.
          2. Имена классов должны быть объявлены с использованием так называемого «StudlyCaps» (каждое слово начинается с большой буквы, между словами нет разделителей).

          Константы

          1. Константы классов должны быть объявлены исключительно в верхнем регистре с использованием символа подчеркивания для разделения слов.
          2. Константы PHP true, false и null должны быть написаны в нижнем регистре.

          Свойства

          1. Область видимости должна быть явно указана для каждого свойства.
          2. В одном выражении не должно быть определено более одного свойства.

          Методы

          1. Метод должен служить одной четко определенной цели, эта цель должна быть полностью отражена в его имени, например: получить текущего пользователя — getСurrentUser() .
          2. Метод не должен иметь слишком большое количество параметров.
          3. Параметры следует упорядочивать по степени их важности либо по порядку их использования внутри метода.
          4. Список аргументов может быть разделен на несколько строк, каждая из которых дополнена слева одним отступом (четырьмя пробелами). В таком случае первый элемент списка аргументов должен начинаться с новой строки, и в каждой строке должен быть указан только один аргумент.
          5. Область видимости должна быть явно указана для каждого метода.

          Переменные
          Переменная должна наиболее полно описывать представляемую сущность, это значит, что она должна иметь понятное название, по которому можно судить о ее предназначении.

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

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

          Область комментирования

          1. В ходе написания кода комментарии описывают константы, методы, классы, свойства интерфейсов.
          2. В коде разрешено комментировать тремя способами:
            1. Для добавления комментария 1 строкой — //;
            2. Для комментирования нескольких строк — /_/ ;
            3. В формате PHPDoc (для описания классов, свойств, методов, констант, интерфейсов).

            Обратите внимание, что комментарий типа # не используется. Это связано с тем, что на основании оставленных комментариев генерируется документация к разрабатываемому программному продукту.

            Порядок составления комментария

            1. Комментарий формируется в следующей последовательности:
              1. класс;
              2. константа;
              3. свойство;
              4. метод.
                Пример формирования комментария “Класс”:

              Требования к комментариям в коде

              1. Комментарий не должен содержать сленговых выражений типа — “юзер”, “штука”, “фигня”, “хрень”, “непонятная вещь”, “задолбался это писать” и т. д.
              2. Комментарий не должен содержать матерных и других неприличных выражений, так как на основе оставленного комментария генерируется документация.
              3. Обязательно необходимо вставлять PHPDoc комментарий передаваемого параметра из «контроллера» в «вид». Обычно такие коментарии встречаются в начале файла /** @var \common\modules\content\models\Post $model */
              4. Обязательно необходимо описывать с помощью PHPDoc комментариев переменные, передаваемые в анонимные функции (Closures) в случае, если тип переменной не описан явно:
              5. В случае явного описания типа переменной в PHPDoc комментарии нет необходимости:

              Рекомендации к комментированию кода

              1. Не нужно комментировать очевидные вещи.
              2. Если код использует стандартные функции, конструкции или классы языка, то не тратьте свое время на его комментирование, в данном случае поможет правильно оформленный код.

              Комментарии к полям (столбцам) таблиц БД

              Во время проектирования таблиц БД необходимо добавлять комментарии для полей таблиц:

              Компонент gii во фреймворке Yii2 позволяет генерировать AR модели для таблиц БД. Установив галочку “Generate Labels from DB Comments”,

              мы получим указанные комментарии в методе attributeLabels , который задает метки атрибутов.

              А также название полей появятся в веб-приложении для администрирования СУБД.

              Источники:

              https://p0vidl0.info/yii-2.html

              https://code. tutsplus. com/ru/tutorials/how-to-program-with-yii2-validations—cms-23418

              https://task-on. com/platforma-taskon/rekomendacii-programmirovanie-yii-2

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: