Контрольные заметки для сертификационного экзамена Мадженто-разработчика – ч.1

Основы – доля в экзамене: 6%.

 

Magento использует объектно-ориентированное программирование (ООП) в качестве парадигмы, которая состоит из Классов, Объектов и Методов. Движок также использует шаблон проектирования Model-View-Controller (MVC).

Magento использует событийно-ориентированную архитектуру (Event Driven Architecture – EDA). Именно здесь компоненты системы является или производителями, или потребителями событий. EDA предполагает наличие свободно связанных, распределенных программных модулей, и по своему характеру является реакционной системой, которая осуществляет действия на основе стимулов.

 

Шаблоны Программирования

Есть многочисленные шаблоны программирования, которые используются в Magento:

 

Factory (Фабрика)

<?php $product = Mage::getModel('catalog/product'); ?>

 

Singleton

<?php $category = Mage::getSingleton('catalog/session'); ?>

 

Registry

<?php $currentCategory = Mage::registry('current_category'); ?>

 

Event/Observer

<?php Mage::dispatchEvent('event_name', array('key'=>$value)); ?>

 

<config>
 <global>
  <events>
   <event_name>
    <observers>
     <unique_name>
       <class>Class_Name</class>
       <method>methodName</method>
     </unique_name>
    </observers>
   </event_name>
  </events>
 </global>
</config>

 

Prototype

<?php Mage::getModel('catalog/product')->getTypeInstance(); ?>

 

Object Pool (Пул объектов)

<?php
  $id = Mage::objects()->save($object);
  $object = Mage::objects($id);
?>

 

Iterator (Итератор)

<?php Mage::getModel('catalog/product')->getCollection(); ?>

 

View Helper (Помощники интерфейса)

<?php Mage::helper('core'); ?>

 

Конструкторы

Magento использует public __construct методы и частично, protected _construct методы класса инициализации. Аргументы могут быть переданы Моделям, созданным с помощью фабрик, с использованием второго аргумента, например,

<?php
$instance = Mage::getModel('prefix/model', array (
  'argument_one' => $value_one,
  'argument_two' => $value_two
));
?>

Параметр аргумента в getModel будет передан как есть. Нет возможности указать конструктору более одного аргумента. Чтобы обойти это ограничение, мы используем массив.

 

Архитектура Высокого Уровня

Code Pools (Области кода)

Magento разделен на три области кода.

• core: Содержит основные модули, разработанные командой Magento.
• community: Содержит модули (расширения) от сторонних разработчиков.
• local: Специальные, пользовательские модули, настройки и переопределения.

 

Типовая структура модуля

Модуль декларируется (объявляется) в файле app/etc/modules/{namespace}_{module name}.xml

Здесь определяется сам модуль, область кода, в которой он находится (codepool) и включается/выключается.

 

Код Модуля

app/code/{codepool}/{namespace}/{module name}

Папка содержит конфигурацию и весь код модуля. Она включает подпапки:

• Блоки: Blocks/
• Контроллеры: controllers/
• Файлы конфигурации: etc/
• Модели: Model/
• Ресурсы модели: Model/Resource/
• Помощники (хелперы): Helpers/
• Установка базы данных и скрипты обновления БД: sql/
• Скрипты данных: data/

 

Шаблоны (Templates) Magento и файлы Макету (Layout)

app/design/{area}/{package}/{theme}/

Макет и файлы шаблонов хранятся в папках области магазина, пакета тем и непосредственно темы. В этих папках файлы макетов и файлы шаблонов разделены на папки layout/ и template/.

 

Magento Skin и файлы JavaScript

skin/{area}/{package}/{theme}

Как и с файлами шаблонов, большинство ресурсов дизайна Magento (JS, CSS и частично изображение) распределены по каталогам области магазина, пакета тем и непосредственно темы. Внутри ресурсы могут быть сгруппированы в своих папках, но это не обязательно.

Например, каталог js/ будет содержать основные JavaScript файлы темы.

 

Области дизайна Magento

adminhtml: Содержит файлы, касающиеся административной части Magento.

frontend: Содержит макеты, шаблоны и ресурсы для фронтэнда (клиентской части сайта) Magento.

 

Конвенция именования классов и автозагрузчик

Загрузка в Мадженто просматривает путь к файлам (app/code) и библиотек (lib/) в каждой из областей кода (core, community, local). Классы будут загружены с помощью стандарта автозагрузки PSR-0. То есть, автозагрузчик просто заменяет подчеркивание в имени класса разделителем каталогов и добавляет .php расширение:

<?php
public function autoload($class)
{
  $classFile = str_replace(' ', DIRECTORY_SEPARATOR, ucwords(str_replace('_', ' ', $class)));
  $classFile.= '.php';
  @include $classFile;
}
?>

 

В Magento действует такое соглашение об именовании классов:

{Namespace}_{Module name}_{Object type}_{Object name}

 

Решение конфликтов модулей

Конфликты могут возникать в трех направлениях:

Конфликты конфигурации:

• Два модуля могут быть расширены с того же класса или они делают изменение конфигурации в тех же областях. Вы можете указать приоритет с тегом явной зависимости <depends> в объявленном модуле, заставляя один модуль загружаться до начала загрузки другого.

Конфликт перезаписи (rewrite):

• Модели Magento и Блоки могут быть перезаписаны только один раз в файлах config.xml. Но мы можем указать последовательность их перезаписи (страхуясь от одновременного их применения).

Конфликты Тем:

• Изменение макета (перемещение, удаление и замена блоков, или изменение их шаблонов) может привести к конфликту, если другие модули зависят от этой структуры. Нужно исследовать конфигурацию шаблонов и модулей, чтобы найти причины конфликтов и соответственно решить их.

 

Конфигурация Magento

Загрузка конфигурации

Конфигурация в Magento сохраняется в виде дерева XML. Magento считывает с каждого модуля файлы config.xml и объединяет их в одно дерево. Это позволяет модулям изменять существующие элементы конфигурации и добавлять новые.

 

Конфигурация группы Классов и Фабричные методы

В Magento Модели, Блоки и Помощники регистрируются в конфигурации с использованием следующей формы:

<config>
 <global>
  <{object type}>
   <{module identifier}>
    <class>{class prefix}</class>
   </{module identifier}>
  </{object type}>
 </global>
</config>

Эти объекты затем инстанциируются в коде с использованием фабричных методов (Mage::getModel() или Mage::helper()) и вызываются с помощью своих сгруппированных имен класса – {идентификатор модуля}/{идентификатор объекта}. Движок Magento использует идентификатор модуля (часть перед слешем) для нахождения префикса имени класса, а часть URI после слеша – для выявления пути размещения класса. Это позволяет модулям переопределять существующие объекты и функциональность, изменяя лишь конфигурацию.

 

Переопределение Класса

Классы объектов могут быть переопределены в конфигурации с использованием следующего синтаксиса:

<config>
 <global>
  <{object type}>
   <{module identifier}>
    <rewrite>
     <{object name}>{new class}</{object name}>
    </rewrite>
   </{module identifier}>
  </{object type}>
 </global>
</config>

Это указывает фабричному методу, что указанный в конфигурации класс следует использовать вместо обычного класса.

 

Регистрация наблюдателя (Observer)

Наблюдатели регистрируются в Magento с использованием следующего синтаксиса:

<config>
 <{area}>
  <events>
   <{event name}>
    <observers>
     <{observer name}>
      <type>{type}</type>
      <class>{class}</class>
      <method>{method}</method>
     </{observer name}>
    </observers>
   </{event name}>
  </events>
 </{area}>
</config>

Здесь нужно указывать область действия (area) для слушателя событий (frontend, adminhtml или global), отслеживаемые события (event), идентификатор обсервера (с уникальным именем), тип наблюдателя (например, одиночная Модель), используемый Класс и Метод для вызова этого события.

 

Функции и использование доступных автоматических событий

Magento делает передачу ряда событий, которые могут наблюдаться автоматически, например, *_save_before и *_load_after.

Это дает нам возможность менять Модели в нужной точке, прежде чем они будут сохранены в базе данных или изменят Модель сразу после того как данные будут получены из базы данных.

 

Операции по расписанию (Cron Jobs)

Планировщики задач определяются в Magento с использованием следующего синтаксиса:

<config>
 <crontab>
  <jobs>
   <{cronjob identifier}>
    <schedule>{schedule}</schedule>
    <run>
      <model>{grouped class name}::{method name}</model>
    </run>
   </{cronjob identifier}>
  </jobs>
 </crontab>
</config>

Расписание планировщика задач (schedule) может быть либо выражением расписания планировщика (внутри тега <cron_expr>), или конфигурационным путем (внутри тега config_path), в котором хранится выражение расписания планировщика задач. Тег <model> определяет выполняемую функцию в формате {grouped name class}::{method name}.

 

Загрузка активных модулей

Magento создает централизованный список установленных модулей при загрузке всех *.xml файлов с app/etc/modules. В нем записывается активны ли модули и путь расположения их области конфигурации (<codepool>).

<?xml version="1.0" ?>
<!-- Файл: app/etc/modules/Meanbee_Royalmail.xml -->
<config>
 <modules>
  <Meanbee_Royalmail>
   <active>1</active>
   <codePool>community</codePool>
   <depends>
     <Mage_Shipping />
   </depends>
  </Meanbee_Royalmail>
 </modules>
</config>

 

Общие методы загрузки конфигурации:

• Mage::app()->getConfig()->getNode();
• Mage::getStoreConfig();
• Mage::getStoreConfigFlag();

 

Конфигурация для магазина в XML DOM

Значение конфигурации для магазина расположены в stores->{имя магазина} части конфигурации и обычно получаются методом Mage::getStoreConfig().

 

Настройка префиксов класса

Префиксы используются для Блоков, Моделей и Помощников. Использование префиксов вместо прямого обращения к классам по их имени позволяет переписывать классы в конфигурации и позволяет не вносить изменения в код, который они используют.

 

Интернационализация

Вид магазинов (store views), как правило, используется для интернационализации, ведь каждый из них может быть настроен под конкретный язык.

В шаблонах есть методы $this->__('Translate Me'), используемые для переводов текста. Они обрабатываются с помощью классов Mage_Core_Helper_Data и Mage_Core_Model_Translate.

Перед выводом в браузере эта строка проверяется в нескольких локациях. Приоритетом для перевода является следующий порядок:

1. Перевод inline: таблица core_translate базы данных
2. Переводы в Теме: app/design/$area/$package/$theme/locale/
3. Переводы в Модуле: app/locale/

 

Если включен режим разработчика, Magento не использует переводы, не связанные с модулем.

Перевод непосредственно для модуля:

"Namespace_Module::string","translation"

 

Установление поддоменов и поддиректорий

Чтобы использовать интернационализацию, вид магазина (store view) должен быть инициализирован с соответствующими настройками. Есть два способа, как это может быть реализовано: через поддомен, например fr.example.com и через поддиректорию, например, example.com/fr.

Есть преимущества и недостатки каждого из этих способов. Но в целом, поддомены и поддиректории достигают одного и того же эффекта.

Поддомены легче для связывания контента. Еще одно преимущество поддоменов заключается в том, что они могут быть размещены на разных серверах. Это может идеально подходить для локализации по стране или региону, в соответствии с языком, используемым в магазине.

С поддиректориями мы усиливаем значение основного домена. И наслаждаемся тем преимуществом, что все магазины работают на повышение общего SEO. Но здесь мы жертвуем возможностью чистых URL для домена бренда (например, http://amazon.com и http://amazon.de против http://amazon.com и http://amazon.com/germany).

 

Перевод на русский: SebWeo