Контролер (controller) - це екземпляр класу CController або успадкованого від нього класу. Він створюється об'єктом докладання в разі, коли користувач його запитує. При запуску контролер виконує відповідну дію, що зазвичай має на увазі створення відповідних моделей і відображення необхідних уявлень. У найпростішому випадку дія - це метод класу контролера, назва якого починається на action.
У контролера є дія за замовчуванням, яке виконується в разі, коли користувач не вказує дію при запиті. За замовчуванням ця дія називається index. Змінити його можна шляхом установки значення CController :: defaultAction.
Наступний код визначає контролер site з діями index (дія за замовчуванням) і contact:
1. Маршрут ¶
Контролери і дії орієнтуються на їхню ідентифікаторів. Ідентифікатор контролера - це запис формату path / to / xyz. відповідна файлу класу контролера protected / controllers / path / to / XyzController.php. де xyz слід замінити реальним назвою класу (наприклад, post відповідає protected / controllers / PostController.php). Ідентифікатор дії - це назва методу без префікса action. Наприклад, якщо клас контролера містить метод actionEdit. то ідентифікатор відповідного дії - edit.
Примітка: За замовчуванням маршрути чутливі до регістру. Це можливо змінити шляхом установки властивості CUrlManager :: caseSensitive рівним false в конфігурації програми. У режимі, не чутливому до регістру, переконайтеся, що назви директорій, що містять файли класів контролерів, вказані в нижньому регістрі, а також, що controller map і action map використовують ключі в нижньому регістрі.
Додаток може містити модулі. Маршрут до дії контролера всередині модуля задається в форматі moduleID / controllerID / actionID. Більш детально це описано в розділі про модулях.
2. Створення примірника контролера ¶
Примірник контролера створюється, коли CWebApplication обробляє вхідний запит. Отримавши ідентифікатор контролера, додаток використовує такі правила для визначення класу контролера і його місця розташування:
якщо встановлено властивість CWebApplication :: catchAllRequest. контролер буде створений на основі цієї властивості, а контролер, запитаний користувачем, буде проігноровано. Як правило, це використовується для установки програми в режим технічного обслуговування і відображення статичної сторінки з відповідним повідомленням;
якщо ідентифікатор контролера виявлений в CWebApplication :: controllerMap. то для створення екземпляра контролера буде використана відповідна конфігурація контролера;
якщо ідентифікатор контролера відповідає формату 'path / to / xyz'. то ім'я класу контролера визначається як XyzController. а відповідний клас як protected / controllers / path / to / XyzController.php. Наприклад, ідентифікатор контролера admin / user буде відповідати класу контролера - UserController і файлу protected / controllers / admin / UserController.php. Якщо файл не існує, буде згенеровано виняток CHttpException з кодом помилки 404.
При використанні модулів процес, описаний вище, буде виглядати дещо інакше. Зокрема, додаток перевірить, чи відповідає ідентифікатор контролера всередині модуля. Якщо відповідає, то спочатку буде створений екземпляр модуля, а потім екземпляр контролера.
3. Дія ¶
Як було згадано вище, дія - це метод, ім'я якого починається на action. Більш просунутий спосіб - створити клас дії і вказати контролеру створювати екземпляр цього класу при необхідності. Такий підхід дозволяє використовувати дії повторно.
Для створення класу дії необхідно виконати наступне:
Щоб контролер знав про цю дію, необхідно перевизначити метод actions () в класі контролера:
У наведеному коді ми використовуємо псевдонім маршруту application.controllers.post.UpdateAction для вказівки файлу класу дії protected / controllers / post / UpdateAction.php. Створюючи дії, засновані на класах, можна організувати додаток в модульному стилі. Наприклад, наступна структура директорій може бути використана для організації коду контролерів:
Прив'язка параметрів дій
Починаючи з версії 1.1.4, в Yii з'явилася підтримка автоматичної прив'язки параметрів до дій контролера. Тобто можна задати іменовані параметри, в які автоматично потраплятимуть відповідні значення з $ _GET.
Для того щоб показати, як це працює, припустимо, що нам потрібно реалізувати дію create контролера PostController. Дія приймає два параметри:
Швидше за все, для отримання параметрів з $ _GET в контролері нам доведеться написати наступний нудний код:
Використовуючи параметри дій, ми можемо отримати більш приємний код:
Ми додаємо два параметра методу actionCreate. Ім'я кожного має в точності збігатися з одним з ключів в $ _GET. Параметру $ language задано значення за замовчуванням en. яке використовується, якщо в запиті відповідний параметр відсутній. Так як $ category не має значення за замовчуванням, в разі відсутності відповідного параметра в запиті буде автоматично викинуто виключення CHttpException (з кодом помилки 400).
Починаючи з версії 1.1.5, Yii підтримує вказівку масивів як параметрів дій. Використовувати їх можна наступним чином:
Ми додаємо ключове слово array перед параметром $ categories. В результаті, якщо параметр $ _GET [ 'categories'] є простою рядком, то він буде приведений до масиву, який містить вихідний рядок.
Примітка: Якщо параметр оголошений без вказівки типу array. то він повинен бути скалярним (тобто не масивом). У цьому випадку передача масиву через $ _GET параметр призведе до виключення HTTP.
Починаючи з версії 1.1.7, автоматична прив'язка параметрів працює і з діями, оформленими у вигляді класів. Якщо метод run () в класі дії описати з параметрами, то ці параметри наповнюються відповідними значеннями з HTTP-запиту:
4. Фільтри ¶
Фільтр - це частина коду, яка може виконуватися до або після виконання дії контролера в залежності від конфігурації. Наприклад, фільтр контролю доступу може перевіряти, аутентифікований користувач перед тим, як буде виконано запитане дію. Фільтр, який контролює продуктивність, може бути використаний для визначення часу, витраченого на виконання дії.
Дія може мати безліч фільтрів. Фільтри запускаються в тому порядку, в якому вони вказані в списку фільтрів, при цьому фільтр може запобігти виконанню дії і наступних за ним фільтрів.
Фільтр може бути визначений як метод класу контролера. Ім'я методу повинно починатися на filter. Наприклад, метод filterAccessControl визначає фільтр accessControl. Метод фільтра повинен виглядати так:
де $ filterChain - екземпляр класу CFilterChain. представляє собою список фільтрів, асоційованих з запитаним дією. У коді фільтра можна викликати $ filterChain-> run () для того, щоб продовжити виконання наступних фільтрів і дії.
Фільтр також може бути екземпляром класу CFilter або його похідного. Наступний код визначає новий клас фільтра:
Для того щоб застосувати фільтр до дії, необхідно перевизначити метод CController :: filters (). повертає масив конфігурацій фільтрів. наприклад:
Даний код визначає два фільтри: postOnly і PerformanceFilter. Фільтр postOnly заданий як метод (відповідний метод вже визначено в CController), в той час як PerformanceFilter - фільтр на базі класу. Ім'я користувача application.filters.PerformanceFilter вказує на файл класу фільтра - protected / filters / PerformanceFilter. Для конфігурації PerformanceFilter використовується масив, що дозволяє задати початкові значення властивостей фільтра. В даному випадку властивість unit фільтра PerformanceFilter ініціалізується значенням 'second'.
Використовуючи оператори '+' і '-' можна вказати, до яких дій повинен і не повинен бути застосований фільтр. У наведеному прикладі postOnly буде застосований до дій edit і create. а PerformanceFilter - до всіх дій, крім edit і create. Якщо оператори '+' і '-' не вказані, фільтр буде застосований до всіх дій.