1.2 Опишіть структуру тек Magento 2

💡 НЕОБХІДНО ЗАПАМʼЯТАТИ:
Модулі Magento знаходяться /app/code/Magento або vendor/Magento
Файли які повʼязані з веб-інтерфейсом знаходяться у view/

Визначте як знайти файли різних типів у Magento 2
/Api: Сервісні Контракти (Service Contracts)
/Api/Data: Дані сервісних контрактів (Data Service Contacts)
/Block: View Models (або шаблон «помічники» ("assistants"))
/Console: Консольні команди
/Controller: Обробники веб-запитів (Web Request Handlers)
/Controller/Adminhtml: Адмін контроллери
/Cron: Cron Job Classes
/etc: Конфігураційні файли
/Helper: Іноді корисно для невеликого, багаторазово використовуваного коду
/i18n: Локалізація (CSV файли)
/Model: Обробка даних і Структури (Data Handling and Structures)
/Model/ResourceModel: Взаємодія з базою даних
/Observer: Слухачі подій
/Plugin: Модифікація функції
/Setup: Модифікація бази даних
/Test:
/Ui: Постачальники даних UI компонентів (UI Component Data Providers)
/view/[area]/layout: директиви XML макетів (layout)
/view/[area]/templates: Шаблони блоків
/view/adminhtml/ui_component: UI компоненти
/view/[area]/web: Web активи (assets)
/view/[area]/web/template: JS шаблони
/view/[area]/requirejs-config.js
Де знаходяться файли, що містять Javascript, HTML і PHP
Як ви знайдете файли, що відповідають за певні функції?

Визначте як знайти файли різних типів у Magento 2

Magento 2 пропонує дуже гнучку систему для побудови і структурування модулів. Наведені нижче відповіді це гібрид кращих практик Magento та тієї свободи що дають вам назви тек та файлів.

Основі файли (core) Magento 2 розташовані у /vendor/magento або /app/code/Magento (у випадку якщо ви завантажили Magento з github). Деякі файли підтримки JS та CSS знаходяться у /lib.

/Api: Сервісні Контракти (Service Contracts)

Тека /Api зберігає контракти для модулів, які містять специфічні дії (actions), які можна надійно використовувати в різних місцях додатку. Наприклад: \Magento\Catalog\Api\CategoryListInterface.

/Api/Data: Дані сервісних контрактів (Data Service Contacts)

Ця тека містить інтерфейси що представляють дані. Наприклад - інтерфейс продукт (Product), інтерфейс категорія (Category) або інтерфейс користувач (Customer). Конкретні реалізації цих інтерфейсів зазвичай роблять трішки більше ніж надають геттери (getters) та сеттери (setters) для даних (aka Обʼєкти Передачі Даних (Data Transfer Objects)).

/Block: View Models (або шаблон «помічники» ("assistants"))

В шаблонах повинно бути використано мінімальну кількість коду PHP (розпроділення відповідальності: дивтись тут і тут). Як результат, блоки Magento виконують або надають бізнес логіку для шаблонів. В MVVM (модель, вид(view), вид-модель(view-model)) методологія Magento використовує Блоки (Blocks) як моделі предсталення (View Models).

Однією з проблем успадкування шаблонного блоку - це дуже роздутий конструктор. Це ускладює тестування і повторне використання. Вирішенням цієї проблеми є використання моделі представлення (View Model). І хоча представлення моделей (View Models) знаходиться в теці Block/ вони дуже різні. Представлення моделі (View Model) надає бізнес логіку для блоку, а не функціональність рендерінгу. Це ще одна відмінність у коді, де блок відповідає за виведення свого вмісту, а модель представлення (view model) - за логіку.

Щоб створити блок з моделю представлення (view model), ви повинні зробити щось схоже (адаптер з vendor/magento/module-backend/Block/Template.php):

<block name="companyname.test" template="CompanyName_ModuleName::template.phtml" >
    <arguments>
        <argument name="viewModel" xsi:type="object">CompanyName\ModuleName\Block\Test</argument>
    </arguments>
</block>

🔗 Корисні посилання:

/Console: Консольні команди

Під час запуску bin/magento в консолі, виводиться перелік доступних команд для запуску. Код для команд повинен знаходитись в теці /Console. Приклад консольної команди bin/magento catalog:product-attrbutes:cleanup: /vendor/magento/module-catalog/ Console/Command/ProductAttributesCleanUp.php.

/Controller: Обробники веб-запитів (Web Request Handlers)

Коли сторінка запитується з сайту Magento, шлях розбивається (parsed) і співвідноситься (matched) з параметрами знайденими в routes.xml і файлами знайденими в теці /Controller.

🔗 Корисні посилання:

Це магічний шлях (magіc path). Magento очікує що адмін контроллери будуть знайдені в цій теці.

/Controller/Adminhtml: Адмін контроллери

📌 MAGENTO 1
Памʼятаєте ще в Magento 1 "старенькі-добренькі-часи" де всі adminhtml файли Magento зберігались в app/code/core/Mage/Adminhtml (Mage_Admnhtml модуль)? Тепер admin контроллери знаходяться безпосередньо всередині теки самого модуля.

/Cron: Cron Job Classes

Ця тека - стандартне місце зберігання дій (actions) які запускаються за розкладом (cron job).

/etc: Конфігураційні файли

В цій теці знаходяться конфігураційні файли. Наприклад: module.xml, crontab.xml, config.xml, webapi.xml, di.xml.

Будь які файли котрі розташовані в теці etc - глобальні. Область (area) цих файлів можна контролювати, розташовуючи файли в папці з ім'ям необхідної області. Наприклад: di.xml який розташовується в теці etc/frontend застосовуватиметься тільки на зовнішньому інтерфейсі (frontend).

Деякі файли повинні бути в папці області (routes.xml и sections.xml), деякі шлобальні (acl.xml) і деякі можуть бути, і глобальними, і обмежені областю(di.xml).

/Helper: Іноді корисно для невеликого, багаторазово використовуваного коду

У Magento 2 ця тека більше непотрібна. Тим не менш, ядро досі використовує цю папку для зберігання дій (actions).

Кожен метод має бути оголошений статичним (незалежно так це чи ні). У класі помічника (helper class) не зберігаються тимчасові дані (крім впроваджених (injected) класів).

📌 MAGENTO 1
Подумайте, чи є ще більш підходяще місце для того, щоб розташувати код, перш ніж додавати його в загальний простір імен (generic namespace). Оскільки ми більше не обмежені структурою папок Magento, можна створювати інші папки, які більшою мірою відображають свою суть. Наприклад: /Query/TestQuery замість /Helper/Query/TestQuery

/i18n: Локалізація (CSV файли)

Ця тека, де розташовуються всі CSV файли для перекладу інтерфейсу. У Magento 1 ці файли розташовувалися в app/locale/de_DE/.

Ці CSV файли складаються з двох колонок: Було (From), Стало (To).

/Model: Обробка даних і Структури (Data Handling and Structures)

В акронімі MVVM - це тека дім для Моделей (Models). Велика кількість класів, які були розташовані раніше в папці /Helper були перенесені в теку /Model. Ця папка містить усе що пов'язано зі структурою даних (vendor/magento/module-catalog/Model/Product.php) для завантаження цих даних (vendor/magento/module-catalog/Model/ProductRepository.php).

/Model/ResourceModel: Взаємодія з базою даних

Тут представлено те, як дані отримують і зберігають у базу даних. Будь-яка пряма взаємодія з базою даних має відбуватися в цих файлах. Це приклад продуктової ресурс моделі (vendor/magento/module-catalog/Model/ResourceModel/Product.php).

/Observer: Слухачі подій

Коли Magento запускає подію, викликаються пов'язані з нею слухачі. Це роз'єднує систему. Magento інтегрована з RabbitMQ, що дає ще більше контролю та надійності в цьому процесі. Дані про подію повинні бути збережені в чергу, і виконатись пізніше.

Слухачі подій повинні реалізовувати (implement) ObserverInterface (\Magento\Framework\Event\ObserverInterface). Клас спостерігача має бути зрозумілий як призначення його функції. Клас PHP повинен дотримуватися позиції використання TitleCase, а ім'я події має бути snake_case. Намагайтеся не поміщати бізнес-логіку в спостерігач. Помістіть логіку в інше місце і додайте цей клас у свій Observer. Коли вам потрібно буде використовувати цю логіку в іншому місці системи, ви скажете собі дякую.

/Plugin: Модифікація функції

Плагіни це одна з найпотужніших особливостей Magento 2. Вона дає змогу вам модифікувати або змінювати функціональність майже будь-якого класу або інтерфейсу. Плагіни працюють тільки з об'єктами, екземплярами яких є ObjectManager.

Плагіни можуть розташовуватися де завгодно. Magento розташовує їх у папці /Plugins що робить їх пошук дуже простим. Я вважаю за краще додавати в назву "Plugin" після імені класу, який модифікується. Якщо я модифікую метод у \Magento\Catalog\Api\Data\ProductInterface,я створюю наступний клас class:/Plugins/Magento/Catalog/ProductPlugin.php. Це зменшує плутанину під час імпорту класів. Інший підхід полягає в тому, щоб назвати плагін безпосередньо для тієї функції, для якої він написаний. Це допоможе швидше знайти потрібний плагін у структурі модуля (наприклад: MinimumPricePlugin замість ProductPlugin, якщо це плагін для Model\Product).

/Setup: Модифікація бази даних

Перелік файлів:

🔗 Корисні посилання:

/Test:

Тут знаходяться тести модуля./Test/Unit містить модульні тести (unit tests). Ви можете запустити тести за допомогою командного рядка: bin/magento dev:tests: run [all, unit, integration, integration-all, static, statc-all, integrity, legacy, default]

/Ui: Постачальники даних UI компонентів (UI Component Data Providers)

Ця тека містить постачальники даних (data providers) і модифікатори для UI компонентів.

/view/[area]/layout: директиви XML макетів (layout)

XML макети пов'язують блоки(/Blocks) з шаблонами. Це дуже гнучкий спосіб контролювати що і де має відображатися.

/view/[area]/templates: Шаблони блоків

Другом Блоку (Block) є шаблон (template), який відтворює HTML для блоку. Поки блок (у /Block) надає бізнес логіку, шаблон надає те, як буде відображатися для клієнта - результат роботи бізнес логіки. Не забувайте, що найкраще, коли в шаблон потрапляє якомога менше PHP-коду.

Коли розробляєте модуль, майте на увазі, що ця тека має називатися у множині templates.

/view/adminhtml/ui_component: UI компоненти

Оформлення замовлення на фронтенді також є UI-компонентом, але він налаштований з використанням XML макета, а не XML UI компонента. Ви також можете знайти теку /templates в середині папки ui_component що містить деякі шаблони для UI компонентів.

Тека містить XML конфігурації для UI компонентів. Вони використовуються для представлення окремих UI елементів, таких як сітки (grids) і форми (forms), і були розроблені для гнучкої візуалізації користувацького інтерфейсу. Більшість адмін сіток (admin grids) Magento (таких як сітка "Каталог продуктів" і "Замовник (Customer)") складаються з UI компонентів. Оформлення замовлення (checkout) на фронтенді також є UI компонетом.

/view/[area]/web: Web активи (assets)

Це те місце, де розташовані web активи (assets). Це включає в себе JS, CSS (або LESS/SCSS) і зображення.

/view/[area]/web/template: JS шаблони

Тут розташовані HTML шаблони, які можуть бути асинхронно запитані за допомогою Javascript (використовуються для кастомізації Magento за допомогою KnockoutJS). Ці файли часто містять декларативні прив'язки (declarative bindings) KnockoutJS. Ім'я цієї папки вказується в однині template - що може збивати з пантелику, оскільки директорії шаблонів PHTML і XHTML вказуються у множині templates.

/view/[area]/requirejs-config.js

Це RequireJS конфігурація модуля. Ця конфігруація використовується для того, щоб контролювати Javascript залежності, створювати псевдоніми (aliases) і оголошувати міксини (mixins).

Де знаходяться файли, що містять Javascript, HTML і PHP

Javascript: в теці /view/[area]/web/.

HTML: в теці view/[area]/templates (розширення таких файлів .phtml)

PHP: будь-яка тека за виключення view/[area]/web/

Як ви знайдете файли, що відповідають за певні функції?

Наведений вище список файлів і папок докладно описує, де і які файли зберігаються.

Blog Comments powered by Disqus.