Сценарий: я разработчик модуля 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 должны подходить по-своему, и получающаяся в результате хаос / нестандартная загрузка конфигурации - это просто стоимость ведения бизнеса?
Официальная документация , делает хорошую работу по покрытию некоторых из доступных классов, но ничего такого , что примиряет тот факт , что нет четких указаний , по которым конкретной реализация , мы предполагаем использование, или если ожидание каждый модуль решает , как сделать это на его собственный.