В останні кілька років моя робота пов'язана з використанням CMS Drupal. але на дозвіллі я вивчав і just for fun запускав проекти на пітоновскіх фреймворками Django. Flask і Twisted. Зараз я вирішив освоїти основи двох-трьох популярних PHP-фреймфорков і першими я вирішив вивчити Zend Framework 2 і Yii.
Переваривши всю цю інформацію, я прийшов до думки, що офіційний туториал до фреймворку сухуватий:
- в ньому не розповідається про роботу з користувачами, сесіями і правами доступу,
- лише побіжно розглядається така засаднича частина фреймворка як ServiceManager,
- в якості інтерфейсу з базою даних безальтернативно використовується патерн Table Gateway (і відповідна його реалізація в фреймворку),
- використовується вбудований в фреймворк шаблонизатор, який після пітоновского Jinja 2 здається зовсім незручним і примітивним,
- і т.д.
У підсумку, більш-менш задовільний по функціоналу додаток я зміг створити після прочитання книги.
У цій статті я хочу навести приклад розробки простого блогу, в ній буде кілька відмінностей від офіційного туторіал. В першу чергу я постараюся загострити увагу на тих питаннях, які під час вивчення здалися мені недостатньо розкритими в офіційному туторіали. Крім того я буду використовувати деякі технології, альтернативні тим, що використовуються в Zend фреймворку за замовчуванням:
- в першій (поточної) частини я розгляну структуру ZendSkeletonApplication,
- у другій частині розберу розробку власного модуля (форми, робота з БД за допомогою Doctrine ORM, розробка View-плагіна),
- третя частина буде присвячена роботі з користувачами.
У тексті статті іноді будуть відсилання до ісходникам зовнішніх додатків або файлів, що автоматично згенерували композер. У репозиторії цих файлів немає, з цього для більш глибокого вивчення розробляється в цьому туторіали додатки вам потрібно буде встановити необхідний софт самостійно.
ZendSkeletonApplication
(При належній налаштування, команду php composer.phar можна замінити просто на composer. Але далі в статті я буду приводити перший варіант як більш універсальний)
Після її виконання ви отримаєте додаток з наступною структурою (я залишив тільки найцікавіші директорії і файли):
Давайте детально розберемо створені директорії і файли.
структура проекту
composer.json
Почнемо з файлу composer.json в корені проекту. Він має такий вигляд:
У цьому файлі задаються параметри програми, які будуть використовуватися композер. Найцікавішою частиною цього конфіга є секція require, яка містить список зовнішніх бібліотек, від яких залежить додаток. Зараз в списку залежностей є тільки Zend Framework 2, але в майбутньому, ми додамо сюди ще кілька залежностей: Доктрину, Твіг і інші. Після додавання нової залежності досить буде в консолі виконати команду:
і композер завантажить необхідні бібліотеки. Всі зовнішні залежності складаються в директорію vendor. Зараз ми в ній можемо побачити директорії zendframework і composer.
Document root
Document_root нашого застосування знаходиться не в корені проекту, а в директорії public. саме тут знаходиться файл index.php - точка входу в наш проект і саме на роботу з цієї Директорією повинен бути налаштований веб-сервер.
Index.php виконує кілька важливих завдань, дві найцікавіших з них потребує такого типу з'єднання зовнішніх бібліотек, завантаження конфігурації програми і його запуск.
Для підключення зовнішніх бібліотек виповнюється файл init_autoloader.php з кореня проекту, який в свою чергу викликає vendor / autoload.php і слідом за ним автоматично згенерований композер файл vendor / composer / autoaload_real.php. У цьому файлі визначені автолоад-методи для завантажених композер зовнішніх бібліотек. Таким чином, коли ми в коді наших модулів будемо підключати неймспейси виду Zend \ View \ Model \ ViewModel PHP знатиме в яких файлах шукати зазначені неймспейси.
Завантажує конфігураційні файли програми і запускає його. В процесі ініціалізації програми (виклик методу Zend \ Mvc \ Application :: init ()) створюється ServiceManager - ключовий об'єкт, який використовується в багатьох частинах програми. За замовчуванням СервісМенеджер створює ще один ключовий об'єкт - EventManager. Надалі, коли ми будемо створювати свої модулі в їх налаштування ми будемо повідомляти СервісМенеджеру які ще об'єкти необхідно створити для роботи нашого модуля.
Про СервісМенеджере ми ще поговоримо пізніше, а зараз давайте докладніше розглянемо директорію config. У ній знаходиться файл application.config.php. повертає масив з конфігурацією додатка, який може розповісти багато цікавого.
Масив modules містить список включених модулів, зараз у нас включений тільки один модуль Application, але в майбутньому їх буде більше.
Масив module_listener_options містить два цікавих елемента: масиви module_paths і config_glob_paths.
Масив module_paths підказує де шукати Plug-in, за замовчуванням в директоріях vendor - зовнішні залежності, і module - тут будуть знаходитися модулі розроблені нами для нашого проекту.
Config_glob_paths містить маски шляхів до конфігураційним файлів модулів. Регулярний вираз 'config / autoload / .php' означає, що будуть завантажені всі файли виду module_name..php, global.php, local.php з директорії config / autoload.
Таким чином, в першу чергу завантажуються налаштування з файлу config / application.config.php, потім завантажуються налаштування з файлів config / autoload / .php і в останню чергу завантажуються налаштування задані на рівні модулів (про це ми поговоримо пізніше).
Якщо в config / autoload є два файли налаштувань для одного і того ж модуля: глобальний і локальний (module_name.global.php і module_name.local.php), то першим ділом буде завантажений глобальний файл, а за ним локальний, тобто локальні настройки мають пріоритет перед глобальними.
Файли local.php і * .local.php за замовчуванням включені в файл .gitignore (якщо ви використовуєте іншу систему контролю версій, то їх потрібно додати в виключення вручну) і вони повинні використовуватися тільки для налаштувань, що відповідають тільки поточного оточенню. Тобто, якщо у вас проект в тому чи іншому вигляді запускається на декількох різних майданчиках: production, тестової і девелоперських майданчиках, то в глобальних налаштуваннях програми потрібно зберігати дані, актуальні для всіх перерахованих майданчиків, а в локальних - унікальні для кожної площадки, наприклад , дані для доступу до БД.
Крім глобальних для всього програми конфігураційних файлів кожен з модулів може мати свій файл настройок. Такі конфігураційні файли модулів завантажуються в тому порядку, в якому визначено перелік активних модулів в файлі application.config.php. Таким чином, якщо ви хочете в своєму модулі перевизначити налаштування іншого модуля, то ваш модуль повинен бути нижче в цьому списку.
Останньою важливою і поки ще не розглянутої Директорією є директорія modules. У цій директорії будуть перебувати модулі, розроблені нами для нашого застосування. Разом з ZendSkeletonApplication поставляється один модуль Application, але перш ніж вивчати його структуру, давайте розберемося з тим, що таке ServiceManager і навіщо він потрібен.
ServiceManager
Реєструються об'єкти в СервісМенеджере або в кофігураціонном файлі module.config.php в секції service_manager, або в Module.php в методі getServiceConfig (), виглядає це приблизно так (приклад скопійований з документації):
Маючи наведену вище конфігурацію СервісМенеджера в будь-якому нашому контролері тепер ми можемо викликати код виду:
і об'єкт $ user_form буде містити відповідну форму.
Тепер настав час повернутися до модуля Application, що входить в ZendSkeletonApplication.
модуль Application
Дерево каталогів цього модуля виглядає так:
Почнемо з Module.php. Цей файл оголошує клас Module з 3 методами:
Код методу onBootstrap () в цьому модулі відповідає за обслуговування маршрутів типу Segment (про типи маршрутів трохи нижче).
Метод getAutoloaderConfig () повідомляє ядру фреймворка де шукати вихідні коди модуля:
У поточному випадку це директорія modules / Application / src / Application.
У методі getConfig () повертається шлях до файлу налаштувань модуля:
Цим файлом повертається масив з настройками, що містить наступні дані:
- елемент масиву router - це масив містить список маршрутів, що обслуговуються модулем і список контролерів, для кожного з маршрутів.
- view_manager містить шляху до шаблонів, які будуть використовуватися додатком і ряд додаткових налаштувань шаблонізатора.
- service_manager - список об'єктів, які повинні бути ініційовані СервісМенеджером.
- ряд інших налаштувань.
В налаштуваннях модуля Application визначається два маршрути:
Модуль Application містить один єдиний контролер IndexController () з одним єдиним екшеном indexAction (), який повертає сторінку з вітальним повідомленням. Для відображення цієї сторінки використовуються шаблони, що знаходяться в директорії view модуля.
На цьому я б хотів завершити першу частину статті. У другій і третій ми займемося розробкою свого невеликого модуля і підключимо до системи кілька зовнішніх.