Контрольні нотатки для сертифікаційного екзамену Мадженто-розробника – ч.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.xml
Mage_*.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
Останні пости
Найкрасивіші та найбільш вражаючі мости з усього світу (ТОП-10)
Міст — це щось більше, ніж просто споруда, яка поєднує два береги. Для того, щоб… Читати далі
Соломон
Життя нас вчить, що свою пару ми пізнаємо, коли розлучаємося, своїх братів ми пізнаємо, коли… Читати далі
Річард Бах
Жодне бажання не дається тобі окремо від сили, що дозволяє його здійснити. Хоча, можливо, для… Читати далі
Стівен Кінг
Життя — це безперервний досвід, і навіть найгірші моменти займають своє місце у пазлі нашого… Читати далі
невідомий автор
Люди, які люблять самотність, дорого заплатили за дружбу з кимось... (невідомий автор) Читати далі