Magento 2: In che modo gli sviluppatori di moduli devono leggere i propri file di configurazione

Scenario: sono uno sviluppatore di moduli Magento 2. Voglio creare un file di configurazione in app/etc. Voglio che questo file sia "ambito" per area

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

In Magento 1 avrei appena creato un config.xmle sarei sulla buona strada. L'ambito scoping è avvenuto nel file XML stesso. Tuttavia, Magento 2 si avvicina in modo molto diverso

In Magento 2, quali file di classe dovrei creare per leggere questi file di configurazione con ambito. Dalla fonte di Magento 2 non è chiaro quale sia il modo "giusto" per farlo. Il codice principale utilizza più approcci e nessuno di essi è contrassegnato da un @apimetodo. Ciò rende difficile sapere come procedere con questa attività comune per gli sviluppatori di moduli. Come effetto collaterale secondario, rende anche difficile sapere come uno sviluppatore del modulo Magento dovrebbe leggere dai file di configurazione di base.

Da un lato, sembra che la cosa "giusta" da fare sia creare un oggetto lettore di file system. Ad esempio, Magento sembra caricare il import.xmlfile con il seguente

#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\Filesystemclasse base sembra avere un codice per risolvere l'ambito dell'area.

Tuttavia, alcuni dei file di configurazione di Magento sembrano eludere questo schema. Mentre ci sono lettori per questi file ( event.xmlin questo esempio)

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

Esistono anche classi di "dati con ambito" che utilizzano questi lettori.

#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);
    }
}

Questo fa sembrare che le classi di lettori con ambito siano ciò che uno sviluppatore di moduli dovrebbe creare. Ma non tutti i file di configurazione hanno questi lettori con ambito.

C'è un percorso chiaro per gli sviluppatori del modulo Magento 2 da seguire? O è solo qualcosa che gli sviluppatori del modulo Magento 2 dovrebbero affrontare a modo loro, e il conseguente caos / caricamento della configurazione non standard è solo il costo di fare affari?

La documentazione ufficiale fa un buon lavoro nel coprire alcune delle classi disponibili, ma nulla che riconcilia il fatto che non esiste una guida chiara su quale implementazione concreta supponiamo di usare, o se l'aspettativa è che ogni modulo decide come fare questo sul suo proprio.

Per creare un nuovo tipo di configurazione, lo sviluppatore del modulo dovrebbe creare una classe del tipo di configurazione che verrà utilizzata dai client di configurazione.

Per rendere queste classi di tipi il più semplice possibile, tutto il comportamento di lettura dei file di configurazione e memorizzazione nella cache dei dati è stato spostato \Magento\Framework\Config\DataInterfacecon due implementazioni riutilizzabili:

• \Magento\Framework\Config\Data - per tipi di configurazione che hanno senso essere caricati in un solo ambito (eav_attributes.xml solo in globale)
• \Magento\Framework\Config\Data\Scoped - per tipi di configurazione che possono essere caricati su ambiti diversi (events.xml - globale e per area)

Ogni tipo di configurazione dovrebbe avere un Config\DataInterfaceoggetto preconfigurato . La configurazione può essere eseguita con Tipo virtuale o con ereditarietà.

Sebbene lo sviluppatore di moduli possa tecnicamente ereditare il proprio tipo di configurazione Config\DataInterfacedall'implementazione, si consiglia di non estenderlo dalle classi principali. Sempre meglio usare la composizione.

Ora \Magento\Framework\Config\Datae Data\Scopedsolo eseguire la memorizzazione nella cache e delegare la configurazione a \Magento\Framework\Config\ReaderInterface. ReaderInterfacedovrebbe fornire una configurazione valida nel formato dell'array PHP per l'ambito richiesto (se la configurazione è nell'ambito). Più implementazioni di ReaderInterfacesono possibili (per esempio di configurazione di lettura da DB), ma solo Magento navi un lettore generico: \Magento\Framework\Config\Reader\Filesystem.

\Magento\Framework\Config\Reader\Filesystem esegue tutte le operazioni necessarie per leggere i file dal filesystem modulare: leggere i file, unire e convalidare.

Ognuno Config\DataInterfacedovrebbe avere un'istanza configurata separatamente di Config\ReaderInterface. Come ogni istanza nel sistema, è possibile configurare un lettore specifico con Virtual Type o con ereditarietà. Documentazione Magento Descrive tutte le Filesystemdipendenze.

Ogni elemento in questa catena è facoltativo (ad eccezione della stessa Classe di tipo di configurazione) e può essere sostituito con un'implementazione più specifica.

Sembra che la documentazione ufficiale abbia le risposte alla tua domanda.

Al momento della stesura di questo documento, non sembra esserci uno standard per la lettura di un albero di configurazione unito in Magento 2. Ogni modulo implementa le proprie classi di lettura della configurazione, il che significa che spetta a ciascuno sviluppatore decidere come desidera tale unione accadere. Mentre Magento offre alcune classi di azioni per fare ciò, anche tra i codici core l'uso di queste classi è incoerente.