Magento 2: Як повинні розробники модулів читати власні файли конфігурації

Сценарій: Я розробник модулів Magento 2. Я хочу створити файл конфігурації в app/etc. Я хочу, щоб цей файл був "розміщений" за областями

app/etc/my_file.xml
app/etc/frontend/my_file.xml
app/etc/adminhtml/my_file.xml

У Magento 1 я просто створив config.xmlта буду на своєму шляху. Оцінка області відбулася в самому файлі XML. Однак Magento 2 підходить до цього дуже по-різному

У Magento 2, які файли класів потрібно створити для читання цих файлів конфігурації. З джерела Magento 2 незрозуміло, який "правильний" спосіб це зробити. Основний код має декілька підходів, і жоден з них не позначений @apiметодом. Це ускладнює знання про те, як діяти з цим загальним завданням для розробників модулів. В якості другорядного побічного ефекту також важко знати, як розробник модулів Magento повинен читати з основних файлів конфігурації.

З одного боку, здається, що "правильне", що потрібно зробити, це створити об'єкт зчитування файлової системи. Наприклад, Magento, здається, завантажує import.xmlфайл із наступним

#File: vendor/magento/module-import-export/Model/Import/Config/Reader.php
namespace Magento\ImportExport\Model\Import\Config;

class Reader extends \Magento\Framework\Config\Reader\Filesystem
{

    public function __construct(
        //...
        $fileName = 'import.xml',
        //...
    ) {
        parent::__construct(
            $fileResolver,
            $converter,
            $schemaLocator,
            $validationState,
            $fileName,
            $idAttributes,
            $domDocumentClass,
            $defaultScope
        );
    }
    //...
}        

Базовий Magento\Framework\Config\Reader\Filesystemклас виглядає так, що він має код для вирішення області області.

Однак деякі конфігураційні файли Magento, схоже, уникають цього шаблону. Хоча для цих файлів є читачі ( event.xmlу цьому прикладі)

vendor/magento/framework/Event/Config/Reader.php

Існують також класи "набору даних", які використовують ці читачі.

#File: vendor/magento/framework/Event/Config/Data.php
class Data extends \Magento\Framework\Config\Data\Scoped
{
    public function __construct(
        \Magento\Framework\Event\Config\Reader $reader,
        //...
    ) {
        parent::__construct($reader, $configScope, $cache, $cacheId);
    }
}

Таким чином, здається, що класи для читання обчислювачів - це те, що повинен створити розробник модулів. Але не у всіх файлах конфігурації є ці зчитувачі.

Чи існує чіткий шлях, яким слід дотримуватися розробників модулів Magento 2? Або це лише щось, що розробники модулів Magento 2 повинні підходити по-своєму, і отриманий хаос / завантаження нестандартної конфігурації - це лише вартість ведення бізнесу?

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

Щоб створити новий тип конфігурації, розробник модуля повинен створити клас типу конфігурації, який буде використовуватися клієнтами конфігурації.

Щоб зробити ці класи типів максимально спрощеними, всі поведінки читання файлів конфігурації та кешування даних були переміщені до \Magento\Framework\Config\DataInterfaceдвох реалізацій для багаторазового використання:

• \Magento\Framework\Config\Data - для типів конфігурації, які мають сенс завантажуватися лише в одній області (eav_attributes.xml лише у глобальному масштабі)
• \Magento\Framework\Config\Data\Scoped - для типів конфігурації, які можна завантажувати в різних областях (events.xml - глобальний та в районі)

Кожен тип конфігурації повинен мати попередньо налаштований Config\DataInterfaceоб'єкт. Конфігурацію можна здійснити або з Virtual Type, або з успадкуванням.

Хоча розробник модулів може технічно успадкувати тип їх конфігурації від Config\DataInterfaceреалізації, рекомендується не поширюватися з основних класів. Завжди краще використовувати склад.

Тепер \Magento\Framework\Config\Dataі Data\Scopedтільки робити кешування та делегувати читання конфігурації \Magento\Framework\Config\ReaderInterface. ReaderInterfaceповинен надати дійсну конфігурацію у форматі масиву PHP для запитуваної області (якщо конфігурація охоплена). Кілька реалізацій ReaderInterfaceможливі (для конфігурації Приклад читання з БД) , але Magento поставляється тільки один загальний читача: \Magento\Framework\Config\Reader\Filesystem.

\Magento\Framework\Config\Reader\Filesystem чи всі операції, необхідні для читання файлів з модульної файлової системи: читати файли, об'єднувати та перевіряти.

Кожен Config\DataInterfaceповинен мати окремо налаштований екземпляр Config\ReaderInterface. Як і будь-який екземпляр у системі, певний зчитувач може бути налаштований або з Virtual Type, або з успадкуванням. Документація Magento Описує всі Filesystemзалежності.

Кожен елемент цього ланцюга є необов'язковим (крім самого типу Config Type Class) і може бути замінений більш конкретною реалізацією.

Схоже, офіційна документація має відповіді на ваше запитання.

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