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