Контрольні нотатки для сертифікаційного екзамену Мадженто-розробника – ч.2

Потік запитів – частка в екзамені: 7%.

Ініціалізація додатку:

Перевірка конфігурації компілятора
Підключення Mage.php
1. Встановлення функцій ядра та автозавантажувача
2. Реєстрація автозавантажувача
Mage::run()
1. Створення екземпляру Mage_Core_Model_App
2. Створення екземпляру конфігурації Моделі
3. $app->run()
  1. baseInit() – завантаження базової конфігурації та ініціалізація кешу.
  2. initModules() – завантаження конфігурації модуля.
  3. Запуск всіх необхідних SQL скриптів інсталяцій та оновлень
  4. Встановлення locale
  5. initCurrentStore() – завантаження конфігурації магазину і створення екземпляру Моделі магазину
  6. initRequest() – завантаження запитуваної інформації в Моделі
  7. Запуск всіх необхідних скриптів встановлення та оновлення даних
  8. Відправлення запиту (диспатч)

Шлях включення та Реєстратор Автозавантаження

Шлях підключення встановлюється та автозавантажувач реєструється, коли файл 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 дозволить її очистити, якщо необхідно.

Якщо вивід не передається в об’єкт відповіді, але виводиться назовні, це може зберегти заголовки від відправки доки вони не буферовані.

Редиректи

Є два типи переадресації, які можуть бути використані в дії контролера.