Доработка модели Post

Модель Post, сгенерированная при помощи Gii, нуждается в следующих изменениях:

Информация: Модель состоит из набора атрибутов, каждый из которых ассоциируется с соответствующим полем в таблице БД. Атрибуты могут быть описаны явно как переменные класса, либо использоваться без какого-либо описания.

Изменение метода rules()

В первую очередь необходимо определить правила валидации, которые позволят убедиться в том, что данные, введённые пользователем, корректны до их сохранения в БД. К примеру, атрибут status модели Post должен быть целым числом, равным 1, 2 или 3. Консоль Gii генерирует правила валидации для каждой модели. При этом используется структура БД, поэтому некоторые правила могут оказаться неточными.

Основываясь на анализе требований, изменим метод rules() следующим образом:




В коде выше мы определили, что атрибуты title, content и status являются
обязательными для заполнения. Длина title не должна превышать 128 символов.
Значение status может быть 1 (черновик), 2 (опубликовано) или 3 (в архиве).
В tags могут содержаться только буквы, запятые и пробелы. Вводимые пользователем
теги дополнительно нормализуются при помощи normalizeTags. Это делается для того,
чтобы теги были уникальными и правильно разделялись запятыми. Последнее правило
используется поиском и будет описано позже.



Валидаторы, такие как required, length, in и match являются стандартными
валидаторами Yii. Валидатор normalizeTags использует определённый в классе Post
метод. За дополнительной информацией о том, как описывать правила валидации вы
можете обратиться к полному руководству.






где array2string и string2array - новые методы, которые мы должны
определить в классе модели Tag:






Правила, описанные в методе rules(), вызываются по очереди при вызове методов модели
validate() или save().





Примечание: Важно помнить, что атрибуты, описываемые в rules()
  должны вводиться пользователем. Другие атрибуты модели Post, такие как id
  или create_time, заполняемые в коде или напрямую в БД не должны присутствовать
  в rules(). Подробнее это описано в разделе
  Безопасное присваивание значений атрибутам.





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



Изменение метода relations()



Далее укажем в методе relations() связанные с записью объекты. После этого мы
сможем использовать реляционную ActiveRecord (RAR)
для получения связанных с записью данных, таких как информацию об авторе и
комментарии. Сложные SQL запросы с JOIN в этом случае не потребуются.



Определим метод relations():






Также, в классе модели Comment мы описываем две константы, которые используются
в приведённом выше методе:






Связи, описанные в методе relations(), означают следующее:



Задав описанные выше связи, мы можем получить информацию об авторе и
комментариях к записи следующим образом:






Более подробно использование и определение связей описано в
полном руководстве.



Добавляем свойство url



Каждой записи соответствует уникальный URL. Вместо повсеместного
вызова CWebApplication::createUrl для формирования этого URL, мы можем
добавить свойство url модели Post и повторно использовать код для генерации URL.
Позже мы опишем, как получить красивые URL. Использование свойства модели позволит
реализовать это максимально удобно.



Для того, чтобы добавить свойство url, мы добавляем геттер в класс Post:






В дополнение к ID записи, в URL через GET-параметр мы выводим заголовок.
Делается это главным образом для оптимизации под поисковые алгоритмы (SEO).
Подробнее это будет описано в разделе «человекопонятные URL».



Так как CComponent является предком класса Post, геттер getUrl() позволяет
нам писать код вроде $post->url. При обращении к $post->url будет вызван геттер
и мы получим результат его выполнения. Более подробно это описано
в полном руководстве.



Текстовое представление для статуса



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



Для хранения связей между целыми числами и их текстовым представлением, необходимым
другим объектам данных, мы используем таблицу tbl_lookup. Для более удобного
получения текстовых данных изменим модель Lookup следующим образом:






Мы добавили два статичных метода: Lookup::items() и Lookup::item().
Первый возвращает список строк для заданного типа данных, второй — конкретную
строку для заданного типа данных и значения.



В базе данных блога есть два типа данных: PostStatus и CommentStatus.
Первый содержит возможные статусы записи, второй — статусы комментария.



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






Следовательно, для получения списка всех возможных статусов записи (массива строк
с ключами, равными соответствующим им значениям), мы можем воспользоваться кодом
Lookup::items('PostStatus'). А для получения конкретной строки — кодом
Lookup::item('PostStatus', Post::STATUS_PUBLISHED).