Контрольные заметки для сертификационного экзамена Мадженто-разработчика – ч.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