Create, read, update та delete (CRUD) — чотири основних операції, за допомогою яких можна управляти обʼєктами даних. Так як реалізація CRUD є типовим завданням для будь-якого веб-додатка, для автоматизації можна скористатися спеціальними інструментами для генерації коду Gii (також відомим як скаффолдінг).
Примітка: Gii доступний починаючи з версії 1.1.2. До цього ми б використовували yiic shell.
Далі ми опишемо як використовувати цей інструмент для реалізації операцій CRUD записів та коментарів нашого блогу.
Для початку необхідно встановити Gii. Відкриваємо файл
/wwwroot/blog/protected/config/main.php
та додаємо наступне:
return array(
......
'import'=>array(
'application.models.*',
'application.components.*',
),
'modules'=>array(
'gii'=>array(
'class'=>'system.gii.GiiModule',
'password'=>'ваш пароль',
),
),
);
Код вище включає модуль з імʼям gii
, який дозволяє нам використовувати
Gii за наступним URL:
http://www.example.com/blog/index.php?r=gii
Буде запитаний пароль, який ми вказали у /wwwroot/blog/protected/config/main.php
.
Після цього буде показана сторінка з усіма доступними інструментами генерації коду.
Примітка: Код, наведений вище не повинен потрапити на сервер. Інструменти для генерації коду повинні використовуватися тільки при розробці.
Для початку нам необхідно створити класи моделей для кожної із таблиць у БД. Ці класи дозволять нам працювати з БД у стилі ООП, що буде показано далі у цьому посібнику.
Запускаємо Model Generator
.
На сторінці вводимо tbl_user
(імʼя таблиці, що зберігає користувачів) у поле Table Name
,
tbl_
у поле Table Prefix
та натискаємо кнопку Preview
.
Буде показана таблиця, посилання у якій дозволять переглянути код, який ми збираємося згенерувати.
Якщо все у порядку, можна натискати Generate
. При цьому код буде збережений у файл.
Інформація: Так як генератору коду необхідно зберегти код у файли, процес повинен мати права на створення та зміну відповідних файлів. Найпростіше надати процесу права на запис у всю директорію
/wwwroot/blog
. Варто відзначити, що це потрібно зробити лише на машині розробника при використанніGii
.
Повторимо ті самі дії для всіх інших таблиць БД, включаючи
tbl_post
, tbl_comment
, tbl_tag
та tbl_lookup
.
Підказка: Також ми можемо ввести
*
у полеTable Name
. Так ми згенеруємо моделі для кожної таблиці БД за один раз.
На даному етапі у нас будуть створені наступні файли:
models/User.php
містить клас User
, який успадковується від
CActiveRecord та може використовуватися для звернення до таблиці tbl_user
;models/Post.php
містить клас Post
, який успадковується від
CActiveRecord та може використовуватися для звернення до таблиці tbl_post
;models/Tag.php
містить клас Tag
, який успадковується від
CActiveRecord та може використовуватися для звернення до таблиці tbl_tag
;models/Comment.php
містить клас Comment
, який успадковується від
CActiveRecord та може використовуватися для звернення до таблиці tbl_comment
;models/Lookup.php
містить клас Lookup
, який успадковується від
CActiveRecord та може використовуватися для звернення до таблиці tbl_lookup
.Після того, як були створені класи моделі, ми можемо використовувати Crud Generator
для генерації коду операцій CRUD для них. Зробимо це для моделей Post
та Comment
.
На сторінці Crud Generator
введемо Post
(імʼя моделі запису блогу, яку ми створили раніше)
у поле Model Class
та натиснемо Preview
, а потім Generate
.
Повторимо ці ж дії для моделі Comment
.
Розглянемо згенеровані файли у /wwwroot/blog/protected
.
Для зручності згрупуємо їх у файли контролерів та
файли представлень:
файли контролерів:
Controllers/PostController.php
містить клас PostController
, який є контролером,
відповідальним за всі операції CRUD для записів;Controllers/CommentController.php
містить клас CommentController
,
який є контролером, відповідальним за всі операції CRUD для коментарів;файли представлень:
views/post/create.php
— файл представлення, який відображає HTML-форму для створення запису;views/post/update.php
— файл представлення, який відображає HTML-форму для оновлення запису;views/post/view.php
— файл представлення, який відображає детальну інформацію запису;views/post/index.php
— файл представлення, який відображає список записів;views/post/admin.php
— файл представлення, який відображає записи у таблиці з адміністративними командами;views/post/_form.php
— частковий файл представлення, що використовується у
views/post/create.php
та views/post/update.php
. Він відображає HTML-форму для збору інформації про запис;views/post/_view.php
— частковий файл представлення, що використовується у
views/post/index.php
. Він відображає короткий вигляд окремого запису.views/post/_search.php
— файл представлення, що використовується у views/post/admin.php
.
Використовується для форми пошуку.Ми можемо перевірити роботу згенерованого коду, використовуючи наступні URL:
http://www.example.com/blog/index.php?r=post
http://www.example.com/blog/index.php?r=comment
Варто відзначити, що можливості по управлінню записами та коментарями повністю незалежні.
Також, при створенні нового запису або коментаря необхідно вводити такі дані,
як author_id
та create_time
, що в реальному додатку повинно робитися автоматично.
Не турбуйтеся, ми виправимо ці проблеми далі.
На даний момент прототип вже містить більшість можливостей, необхідних нашому блогу.
Щоб краще зрозуміти, як використовуються файли вище, розглянемо, що відбувається при відображенні списку записів:
http://www.example.com/blog/index.php?r=post
;PostController
та виконує його;PostController
виконує дію index
(метод actionIndex()
).
Відзначимо, що index
є дією за замовчуванням та використовується у разі,
якщо користувач не вказав дію у URL;actionIndex()
робить запит до бази даних для отримання списку останніх записів;actionIndex()
генерує представлення index
з даними записів.