Scénario: je suis développeur de modules Magento 2. Je souhaite créer un fichier de configuration dans app/etc
. Je souhaite que ce fichier soit "délimité" par zone
app/etc/my_file.xml
app/etc/frontend/my_file.xml
app/etc/adminhtml/my_file.xml
Dans Magento 1, je venais juste d'en créer un config.xml
et j'étais en route. La délimitation de la zone s'est produite dans le fichier XML lui-même. Cependant, Magento 2 aborde cela très différemment
Dans Magento 2, quel (s) fichier (s) de classe dois-je créer pour lire ces fichiers de configuration étendus. La source Magento 2 ne précise pas quelle est la "bonne" façon de procéder. Le code principal adopte plusieurs approches, et aucune d'entre elles n'est marquée par une @api
méthode. Cela rend difficile de savoir comment procéder avec cette tâche commune de développeur de module. En tant qu'effet secondaire, il est également difficile de savoir comment un développeur de module Magento doit lire les fichiers de configuration principaux.
D'une part, il semble que "la bonne" chose à faire est de créer un objet lecteur de système de fichiers. Par exemple, Magento semble charger le import.xml
fichier avec les éléments suivants
#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
);
}
//...
}
La Magento\Framework\Config\Reader\Filesystem
classe de base semble avoir du code pour résoudre l'étendue de la zone.
Cependant, certains fichiers de configuration de Magento semblent éviter ce modèle. Bien qu'il existe des lecteurs pour ces fichiers ( event.xml
dans cet exemple)
vendor/magento/framework/Event/Config/Reader.php
Il existe également des classes de «données de portée» qui utilisent ces lecteurs.
#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);
}
}
Cela donne l'impression que les classes de lecture étendues sont ce qu'un développeur de module devrait créer. Mais tous les fichiers de configuration n'ont pas ces lecteurs de portée.
Y a-t-il un chemin clair à suivre pour les développeurs de modules Magento 2? Ou est-ce juste quelque chose que les développeurs de modules de Magento 2 devraient aborder à leur manière, et le chaos / chargement de configuration non standard qui en résulte n'est que le coût de faire des affaires?
La documentation officielle couvre bien certaines des classes disponibles, mais rien qui concilie le fait qu'il n'y a pas de directives claires sur l'implémentation concrète que nous supposons utiliser, ou si l'attente est que chaque module décide comment le faire sur son posséder.