Zend_Controller_Front реалізує »патерн Front Controller. використовуваний в додатках »MVC. Його призначення полягає в ініціалізації оточення запиту, прокладанні маршруту приходить запиту і наступному запуску виявлених дій. Він агрегує всі відповіді і повертає їх по завершенні процесу.
Zend_Controller_Front також реалізує »патерн Singleton. це означає, що в будь-який час може бути доступний тільки один екземпляр цього класу. Це дозволяє йому також виступати в якості реєстру, в якому зберігаються інші об'єкти, які беруть участь в процесі диспетчеризації.
Zend_Controller_Front реєструє в собі брокер плагінів (plugin broker), що дозволяє за допомогою плагінів відстежувати події, ініційовані фронт-контролером. У більшості випадків це дає можливість підганяти процес диспетчеризації під конкретний сайт без розширення фронт-контролера для додавання функціональності.
Фронт-контролера для його роботи необхідний, як мінімум, один або більше шляхів для тек, що містить контролери дій. Можна також використовувати різні методи для подальшої настройки конфігурацій фронт-контролера і його помічників.
Note. Поведінка за замовчуванням
За замовчуванням фронт-контролер завантажує плагін ErrorHandler і помічник дій ViewRenderer. Це зроблено для спрощення обробки помилок і рендеринга видів в контролерах, відповідно.
Для того, щоб відключити ErrorHandler. зробіть наступне до виклику методу dispatch ().
// Відключення плагіна ErrorHandler:
$ Front -> setParam # 40; 'NoErrorHandler'. true # 41; ;
Для того, щоб відключити ViewRenderer. зробіть наступне до виклику методу dispatch ().
$ Front -> addControllerDirectory # 40; '../modules/foo/controllers'. 'Foo' # 41; ;
Note. Якщо ви використовуєте addControllerDirectory () без імені модуля, то він встановить директорію для модуля default. Якщо директорія вже існує, то вона буде переписана.
Можна отримати поточні установки для директорій контролерів, використовуючи метод getControllerDirectory (). Він поверне масив пар модуль => директорія.
Однією з можливостей фронт-контролера є те, що ви можете визначати модульну структуру директорій для створення окремих компонент, які називаються "модулями".
Кожен модуль повинен перебувати у власній директорії і відображати структуру директорій використовуваного за замовчуванням модуля - тобто він повинен містити, як мінімум, піддиректорію "controllers"; з нею, як правило, присутня піддиректорія "views" та інші піддиректорії додатки.
Метод addModuleDirectory () дозволяє передавати ім'я директорії, що містить один або більше директорій модулів. Він їх сканує і додає в якості директорій контролерів у фронт-контролер.
Якщо ви хочете отримати шлях до певного модулю або до поточного модулю, то можете використовувати метод getModuleDirectory (). при передачі імені модуля він повертає шлях до нього, інакше повертається шлях до поточного модулю.
dispatch (Zend_Controller_Request_Abstract $ request = null, Zend_Controller_Response_Abstract $ response = null) є "робочою конячкою" фронт-контролера. Він може опціонально приймати об'єкт запиту та / або об'єкт відповіді. що дає розробникам можливість передавати свої об'єкти.
Якщо методу dispatch () були передані об'єкт запиту або відповіді, то він буде перевіряти, чи були раніше зареєстровані об'єкти, і використовувати їх, або інстанціювати версії за умовчанням (в обох випадках за замовчуванням будуть використовуватися різновид HTTP).
Аналогічним чином dispatch () проводить перевірку на вже зареєстровані об'єкти маршрутизатора і диспетчера. і якщо вони не знайдені, то інстанцірует версії за умовчанням.
Процес диспетчеризації має три окремих події:
Маршрутизація проводиться тільки один раз, коли викликається dispatch (). при цьому використовуються значення в об'єкті запиту. Диспетчеризація здійснюється циклічно. Запит може означати виклик кількох дій, контролер або плагін можуть скидати об'єкт запиту для додаткового виклику інших дій. Коли всі дії виконані, фронт-контролер повертає відповідь.
Zend_Controller_Front :: run ($ path) - статичний метод, який приймає тільки шлях до директорії контролерів. Він витягує екземпляр фронт-контролера через getInstance ()), реєструє цей шлях через setControllerDirectory (). і в кінці викликає метод dispatch ().
По суті, run () являє собою зручний метод, який можна використовувати при розробці сайту, що не потребує спеціальної настройки фронт-контролера.
// інстанцірованія фронт-контролера, установка директорії контролера і
// виконання диспетчеризації в одному виклику:
Zend_Controller_Front. run # 40; '../application/controllers' # 41; ;
Крім методів, перерахованих вище, є методи-аксессор, які можна використовувати для управління конфігурацією фронт-контролера - і одночасно конфігурацією класів, яким фронт-контролер делегує виконання.
resetInstance () може використовуватися для скидання всіх поточних налаштувань. Він в основному призначений для тестування, але може також використовуватися в тих випадках, коли потрібно зв'язати між собою кілька фронт-контролерів.
(Set | get) DefaultControllerName () дозволяють встановити інше ім'я використовуваного за замовчуванням контролера (інакше використовується # 'Index #') і отримати поточне значення. Вони служать посередниками до диспетчеру.
(Set | get) DefaultAction () дозволяють встановити інше ім'я використовуваного за замовчуванням дії (інакше використовується # 'Index #') і отримати поточне значення. Вони служать посередниками до диспетчеру.
(Set | get) Request () дозволяють встановити клас запиту або його об'єкт для використання в процесі диспетчеризації і отримати поточний об'єкт. При установці об'єкта запиту ви можете передати ім'я класу запиту, в цьому випадку метод завантажить файл класу і інстанцірует його.
(Set | get) Router () дозволяють встановити клас маршрутизатора або його об'єкт, що використовуються протягом процесу диспетчеризації, і отримати поточний об'єкт. Коли встановлюється об'єкт маршрутизатора, ви можете передати ім'я класу маршрутизатора, в цьому випадку метод завантажить файл класу і інстанцірует його.
Під час вилучення об'єкта маршрутизатора спочатку проводиться перевірка, представлений чи у фронт-контролері такий об'єкт і в разі його відсутності інстанцірует яка буде використовуватися під маршрутизатор (Rewrite Router).
(Set | get) BaseUrl () дають можливість встановити базовий URL. який видаляється з початку при маршрутизації запитів, і отримати його поточне значення. Це значення передається об'єкту запиту безпосередньо до маршрутизації.
(Set | get) Dispatcher () дають можливість установки класу диспетчера або його об'єкта для використання протягом диспетчеризації, і отримання поточного об'єкта. При установці об'єкта диспетчера можна передати ім'я класу диспетчера, в цьому випадку метод завантажить файл класу і інстанцірует його.
Під час вилучення об'єкта диспетчера, метод спочатку проводить перевірку того, представлений чи у фронт-контролері такий об'єкт і в разі його відсутності інстанцірует диспетчер, який використовується за умовчанням.
(Set | get) Response () дають можливість встановити клас відповіді або його об'єкт для використання в процесі диспетчеризації, і витягти поточний об'єкт. При установці об'єкта відповіді можна передати ім'я класу відповіді, в цьому випадку метод завантажить файл класу і інстанцірует його.
registerPlugin (Zend_Controller_Plugin_Abstract $ plugin, $ stackIndex = null) дозволяє реєструвати об'єкти плагінів. Шляхом установки опціонального параметра $ stackIndex. ви можете контролювати порядок, в якому виконуються плагіни.
unregisterPlugin ($ plugin) дозволяє скасовувати реєстрацію об'єктів плагінів. $ Plugin може бути як об'єктом плагіна, так і рядком, що позначає клас плагіна, реєстрацію якого треба скасувати.
throwExceptions ($ flag) використовується для включення / відключення можливості створення виключень протягом процесу диспетчеризації. За замовчуванням виключення відловлюються і розміщуються в об'єкті відповіді; включення throwExceptions () перевизначити цю поведінку
returnResponse ($ flag) використовується для того, щоб вказати фронт-контролера - повертати чи відповідь з dispatch () (TRUE), або відповідь має бути відправлений автоматично (FALSE). За замовчуванням відповідь відправляється автоматично (через виклик Zend_Controller_Response_Abstract :: sendResponse ()); включення returnResponse () перевизначити цю поведінку.
Ситуації, в яких може знадобитися повернення відповіді, включають в себе перевірку на предмет винятків до відправки відповіді клієнту, необхідність журналирования різних аспектів відповіді (таких, як заголовки) і т.д.
У вступі ми вказали на те, що фронт-контролер також виступає як реєстр для різних компонент контролера. Це реалізується через групу методів для параметрів. Ці методи дозволяють реєструвати довільні дані - об'єкти і змінні - у фронт-контролері, щоб їх можна було витягти в будь-якій точці ланцюжка диспетчеризації. Ці значення передаються маршрутизатора, диспетчеру, і контролерам дій. Ці методи включають в себе:
setParam ($ name, $ value) дає можливість встановити єдиний параметр з ім'ям $ name і значенням $ value.
setParams (array $ params) дозволяє встановити кілька параметрів одночасно за допомогою асоціативного масиву.
getParam ($ name) дає можливість отримати один параметр за один раз, використовуючи його ім'я $ name в якості ідентифікатора.
getParams () дозволяє витягти всі параметри за один раз.
clearParams () дозволяє видалити один параметр (шляхом передачі строкового ідентифікатора), кількох параметрів (шляхом передачі масиву строкових ідентифікаторів) або весь стек параметрів (без передачі чого-небудь).
Є кілька визначених параметрів спеціально для використання в ланцюжку диспетчеризації:
useDefaultControllerAlways використовується для вказівки диспетчера. що слід використовувати контролер за замовчуванням в модулі за замовчуванням для будь-яких запитів, диспетчеризація яких неможлива (тобто модуль, контролер і / або дія не існують). За замовчуванням він відключений.
Див. Винятки в MVC, з якими ви можете зустрітися за більш детальною інформацією про використання цього параметра настройки.
disableOutputBuffering використовується для вказівки диспетчера. що не слід використовувати буферизацію виводу для збору даних на висновок, що генеруються контролерами дій. За замовчуванням диспетчер збирає весь висновок і приєднує його до тіла вмісту в об'єкті відповіді.
noViewRenderer використовується для відключення помічника ViewRenderer. Встановіть цей параметр в true для його відключення.
noErrorHandler використовується для відключення плагіна Error Handler Встановіть цей параметр в true для його відключення.
При спадкуванні від фронт-контролера, необхідно, як мінімум, перевизначити метод getInstance ().