Контрольні нотатки для сертифікаційного екзамену Мадженто-розробника – ч.2
Потік запитів – частка в екзамені: 7%.
Ініціалізація додатку:
- Перевірка конфігурації компілятора
- Підключення
Mage.php- Встановлення функцій ядра та автозавантажувача
- Реєстрація автозавантажувача
Mage::run()- Створення екземпляру
Mage_Core_Model_App - Створення екземпляру конфігурації Моделі
$app->run()baseInit()– завантаження базової конфігурації та ініціалізація кешу.initModules()– завантаження конфігурації модуля.- Запуск всіх необхідних SQL скриптів інсталяцій та оновлень
- Встановлення
locale initCurrentStore()– завантаження конфігурації магазину і створення екземпляру Моделі магазинуinitRequest()– завантаження запитуваної інформації в Моделі- Запуск всіх необхідних скриптів встановлення та оновлення даних
- Відправлення запиту (диспатч)
- Створення екземпляру
Шлях включення та Реєстратор Автозавантаження
Шлях підключення встановлюється та автозавантажувач реєструється, коли файл Mage.php підключається в index.php. Незабаром після цього відбувається реєстрація автозавантажувача з spl_autoload_register.
Завантаження конфігурації модуля та бази даних в Magento
Базова конфігурація Magento завантажується в Mage_Core_Model_Config::loadBase. Тут оглядаються глобальні файли app/etc/*.xml, які містять ключову інформацію конфігурації, наприклад облікові дані бази даних, core модулі ядра, та результати інсталяції.
Конфігурація бази даних зберігається в app/etc/local.xml і app/etc/config.xml.
Mage_Core_Model_Config::loadModules проходить циклом по кожному з модулів, які наявні в app/etc/modules/ і об’єднує їх власні config.xml файли з відповідних директорій модуля.
Порядок завантаження модулів:
Mage_All.xmlMage_*.xml- Всі інші
Якщо модуль залежить від іншого, Magento робить припущення, що він існує і завантажує його конфігурацію першим.
Модулі завантажуються після базової конфігурації, але до ініціалізації магазину.
Налаштування виконання сценарію
Завантаження модуля і оновлення баз даних SQL виконуються, коли викликається Mage_Core_Model_App::app(), але оновлення даних не відбувається. У той час як Mage_Core_Model_App::run() завершує все вищесказане. Він робить це в два етапи:
Mage_Core_Model_Resource_Setup::applyAllUpdates()– виконується відразу після завантаження конфігурації модуля і запуску всіх скриптів SQL встановлення та оновлення.Mage_Core_Model_Resource_Setup::applyAllDataUpdates()– виконується післяstore,localeі запитів до моделей, що мають бути ініціалізованими і запускає скрипти встановлення і оновлення даних.
Завантаження магазинів і локалізації Magento
У методі Mage_Core_Model_App::run() Magento обирає, який магазин використовувати у:
<?php $this->_initCurrentStore($scopeCode, $scopeType); ?>
Є кілька способів, щоб вказати поточний магазин:
- Змінні середовища
- Зміна пріоритетів магазину
- GET параметр
__store
Змінні середовища перевіряються в index.php:
<?php /* Store or website code */ $mageRunCode = isset($_SERVER['MAGE_RUN_CODE']) ? $_SERVER['MAGE_RUN_CODE'] : ' '; /* Run store or run website */ $mageRunType = isset($_SERVER['MAGE_RUN_TYPE']) ? $_SERVER['MAGE_RUN_TYPE'] : 'store'; ?>
Об’єкти запиту і відповіді
Об’єкт запиту ініціалізується в Mage_Core_Model_App і в методі _initRequest(). getRequest() і getResponse() є подібними.
Фронт-контролер
Role (роль)
Фронт-контролер виконує маршрутизацію запиту до відповідного контролеру. Він обробляє всі зареєстровані маршрути, передаючи запити кожному з них, зіставляючи з контролером, здатним обробляти його. Після того як запит був відправлений, фронт-контролер посилає відповідь клієнту.
Events (події)
controller_front_init_before– запуск перед додаванням маршрутів. Це корисно для додавання маршруту, який має пріоритет над будь-якими іншими.controller_front_init_routers– запуск після додавання маршруту, але перш ніж додасться маршрутизатор за замовчуванням. Це корисно для додавання загальних маршрутів або модифікування існуючих.controller_front_send_response_before– запуск до того як буде надіслано відповідь. Це корисно для модифікації даних відповіді після відправки.controller_front_send_response_after– запуск, коли відповідь відправлена. Це корисно для виконання будь-якої операції, після того як запит був розглянутий.
Додавання Класів маршрутизатора
Є два способи додавання класів маршруту:
- Використання конфігурації
<config>
<default>
<web>
<routers>
<{name}>
<area></area>
<class></class>
</{name}>
</routers>
</web>
</default>
- Спостерігачем
controller_front_init_beforeабо подієюcontroller_front_init_routersта включенням шляху у фронт-контролер.
URL переадресації
Структура URL
Структура URL в Magento, як правило, використовує формат {base_url}/{front_name}/{controller}/{action}.
Mage_Core_Controller_Varien_Router_Standard розбирає URL в цьому форматі і розмічує для використання в модулі і для виконання в дії контролера.
Процес перезапису посилання
Перезапис URL відбувається у фронт-контролері перед маршрутизацією. Першими перевіряються і застосовуються перезаписи бази даних, а потім конфігураційні перезаписи (global->rewrite).
Перезапис може або переадресовувати запит за допомогою методів HTTP, оновлювати шлях запиту (зберігаючи старий) або повністю замінювати шлях запиту.
Перезаписи URL в базі даних
Найбільш важливими полями в таблиці core_url_rewrite є request_path і target_path, які зберігають запити на перезапис.
Magento створює шляхи каталогу використовуючи індексатор catalog_url.
Відповідність запитів
Запити застосовуються до моделі Mage_Core_Model_Url_Rewrite_Request. Шлях запиту аналізується, щоб включити в нього будь-які зміни (з або без косої риски), а потім оглядає стовпець request_path в таблиці core_url_rewrite, використовуючи метод Mage_Core_Model_Url_Rewrite::loadByRequestPath().
Маршрутизація запитів
Вбудовані маршрутизатори Magento (в порядку відповідності):
- Admin
- Збирає всі маршрути для адміністративної частини сайту
- Оглядає
config.xmlв пошуках admin маршрутів
- Standard
- Суперклас Адміна
- Збирає маршрути всередині frontend маршрутів, визначених у
config.xml
- CMS
- Маршрути CMS сторінок через їх ідентифікатори
- Default
- Тут завжди буде співпадіння
- Маршрути помилок або 404 сторінки
Маршрутизатор standard відображає шлях до дії, розділяючи його на base_url/frontname/controller/action. Frontname потім розмічується в модулі за шляхами в конфігураційних файлах. Місцезнаходження файлу контролера: /path/to/module/base/controllers/{Name}Controller.php
Нерозмічені запити читає Default маршрутизатор, який потім їх перенаправляє на сторінку 404 і розмічує для відображення Standard маршрутизатором в наступній ітерації.
Перед відправленням встановлюються запити модуля, контролер, дія і параметри. Потім він передається на контролер (всі через Standard маршрутизатор).
Дизайн і ініціалізація макету
Дизайн магазину (core/design_package) ініціалізується в контролері методом preDispatch(). Конфігурація пакету і тема потім визначається через Mage_Core_Model_Design.
Файли макету читаються ($layout->getUpdate()->Load()), коли контролер викликає $this->loadLayout(). Той же метод компілює макет ($layout->generateXml()), який обробляє директиви макету.
Вивід генерується, коли контролер викликає $this->renderLayout(), який викликає кожен з визначених блоків у вихідних даних, наприклад, з output="toHtml", і об’єднує їх в тіло відповіді.
Щоб додати зачіпку макету, потрібно викликати
<?php Mage::getLayout()->getUpdate()->addHandle('new_handle'); ?>
За лаштунками Mage_Core_Model_Layout_Update завантажує файли макету та їх XML, поки Mage_Core_Model_Layout обробляє їх.
XML макети об’єднується спочатку з модулів, далі йде local.xml, а потім із бази даних. Наступним кроком є видалення блоків або посилань за вказівкою <remove> елементу.
Щоб додавати файл макету до загальної маси, необхідно додати інструкцію до файлу config.xml:
<config>
<{area}>
<layout>
<updates>
<{name}>
<file>{filename.xml}</file>
</{name}>
</updates>
</layout>
</{area}>
</config>
Цей файл потім будуть шукати в app/design/{area}/{package}/{theme}/layout/{filename.xml}
Очистка даних (вивід)
Зміст відповіді встановлюється методом $layout->renderLayout(). Після того як контролер повернув метод відправки, Фронт-контролер направляє відповідь.
Подію controller_front_send_response_before можна використовувати для модифікації відповіді перед відправкою. Згодом, спостереження за подією controller_front_send_response_after дозволить її очистити, якщо необхідно.
Якщо вивід не передається в об’єкт відповіді, але виводиться назовні, це може зберегти заголовки від відправки доки вони не буферовані.
Редиректи
Є два типи переадресації, які можуть бути використані в дії контролера.
_redirect()– виконує переадресацію HTTP_forward()– внутрішня переадресація до іншого контролера і/або дії.
Адаптація перекладу: SebWeo