Magento 2: Modül Geliştiricileri Kendi Yapılandırma Dosyalarını Nasıl Okumalı


20

Senaryo: Ben bir Magento 2 modülü geliştiricisiyim. İçinde bir yapılandırma dosyası oluşturmak istiyorum app/etc. Bu dosyanın alana göre "kapsamlandırılmasını" istiyorum

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

Magento 1'de sadece bir tane oluşturup config.xmlyola koyulurdum. Alan kapsamı XML dosyasının kendisinde gerçekleşti. Ancak, Magento 2 buna çok farklı yaklaşıyor

Magento 2'de, bu kapsamlı yapılandırma dosyalarını okumak için hangi sınıf dosyalarını oluşturmalıyım? Magento 2 kaynağından bunu yapmanın "doğru" yolunun ne olduğu açık değildir. Çekirdek kod birden fazla yaklaşım benimser ve hiçbiri bir @apiyöntemle işaretlenmez . Bu, bu ortak modül geliştirici görevine nasıl devam edileceğini bilmeyi zorlaştırır. İkincil bir yan etki olarak, bir Magento modülü geliştiricisinin çekirdek yapılandırma dosyalarından nasıl okuması gerektiğini de zorlaştırır .

Bir yandan, yapılacak doğru şey bir dosya sistemi okuyucu nesnesi oluşturmak gibi görünüyor. Örneğin, Magento import.xmldosyayı aşağıdaki gibi yüklüyor

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

Temel Magento\Framework\Config\Reader\Filesystemsınıf, alan kapsamını çözümlemek için koda sahip gibi görünüyor.

Ancak , Magento yapılandırma dosyalarından bazıları bu kalıbı kullanmıyor gibi görünüyor. Bu dosyalar için okuyucular bulunurken (event.xml bu örnekte)

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

Bu okuyucuları kullanan "kapsamlı veri" sınıfları da vardır .

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

Bu, bir modül geliştiricisinin yaratması gereken kapsamlı okuyucu sınıfları gibi görünmesini sağlar. Ancak tüm yapılandırma dosyalarında bu kapsamlı okuyucular yoktur.

Magento 2 modülü geliştiricilerinin izleyeceği açık bir yol var mı? Yoksa bu sadece Magento 2 modül geliştiricilerinin kendi yöntemleriyle yaklaşmaları gereken bir şey mi ve ortaya çıkan kaos / standart dışı konfigürasyon-yükleme sadece iş yapmanın maliyeti mi?

Resmi belgeler mevcut sınıfların bazı kapsayan iyi bir iş, ama aslında uzlaştıran şey somut uygulama biz kullanımına varsayalım konum hangi net bir kılavuz vardır, ya beklenti ise her modül bu konuda nasıl karar verir onun kendi.


Bunun yardımcı olabileceğini düşünüyorum: magento.stackexchange.com/q/51915/146
Marius

@Vinai github.com/magento/magento2/pull/1410 tarafından bu Halkla İlişkiler'i gördünüz ? Özel gereksinimleriniz yoksa, kendi yapılandırma dosyanızı yalnızca sanal türlerle döndürebileceğinizi düşünüyorum.
Kristof at Fooman

Yanıtlar:


4

Yeni yapılandırma türü oluşturmak için modül geliştirici bir yapılandırma türü sınıfı oluşturmalıdır , yapılandırma istemcileri tarafından kullanılacak .

Bu tür sınıfları olabildiğince basit hale getirmek için, yapılandırma dosyalarını ve önbellek verilerini okumadaki tüm davranışlar, \Magento\Framework\Config\DataInterfaceyeniden kullanılabilir iki uygulama ile taşındı :

  • \Magento\Framework\Config\Data - yalnızca bir kapsamda yüklenmesi anlamlı olan yapılandırma türleri için (yalnızca globalde eav_attributes.xml)
  • \Magento\Framework\Config\Data\Scoped - farklı kapsamlara yüklenebilecek yapılandırma türleri için (events.xml - global ve alan başına)

Her yapılandırma türünün önceden yapılandırılmış olması gerekir Config\DataInterface nesneye . Yapılandırma Sanal Tip veya kalıtımla yapılabilir.

Modül geliştiricisi yapılandırma türlerini teknik olarak devralmasına rağmen Config\DataInterface uygulamadan , çekirdek sınıflardan genişletmemeniz önerilir. Kompozisyon kullanmak her zaman daha iyidir.

Şimdi \Magento\Framework\Config\Datave Data\Scopedsadece önbellek ve temsilci yapılandırma okuma yapmak \Magento\Framework\Config\ReaderInterface. ReaderInterface, istenen kapsam için PHP dizisi biçiminde geçerli bir yapılandırma sağlamalıdır (yapılandırma kapsamlıysa). Çoklu uygulamaları ReaderInterfaceancak Magento sadece gemi bir genel okuyucu (DB örnek okuma konfigürasyon için) mümkündür: \Magento\Framework\Config\Reader\Filesystem.

\Magento\Framework\Config\Reader\Filesystem modüler dosya sisteminden dosya okumak için gerekli tüm işlemleri yapar: dosyaları oku, birleştir ve doğrula.

Her Config\DataInterfacebirinin ayrı ayrı yapılandırılmış örneğine sahip olması gerekir Config\ReaderInterface. Sistemdeki herhangi bir örnekte olduğu gibi, belirli okuyucu Sanal Tip veya kalıtımla yapılandırılabilir. Magento Belgeleri Tüm Filesystembağımlılıkları açıklar .

Bu zincirdeki her öğe isteğe bağlıdır (Config Type Sınıfı hariç) ve daha özel bir uygulama ile değiştirilebilir.


1

Gibi görünüyor Resmi belgelerin sorunuza cevap vermektedir.


1
Yanıt verdiğiniz için teşekkür ederiz, ancak belgelerin sorumu yanıtladığından emin değilim. Kullanılabilir bir dizi arabirimi listeler (bu yararlıdır, bunun için +1), ancak bu arabirimlerin ( Magento\Framework\Config\Datave Magento\Framework\App\Config) somut uygulamalarının hiçbirinin @api ile işaretlenmemiş olması gerçeğini uzlaştırmaz . Sadece bu dokümantasyonla bırakılırsa, bir modül geliştiricisi olarak, yapılandırma dosyaları oluşturmak ve okumak için standart bir sistem olmadığı ve istediğim her şeyi yapabileceğim varsayımı altında olurdum . Bu doğru görünmüyor.
Alan Storm

Başka bir modül için yapılandırmayı okumanız gereken durumları açıklayabilir misiniz? Benim için yapılandırma okuyucu modülün özel API'sı.
KAndy

Bir geliştirici Magento çekirdeğine katkıda bulunmak istiyorsa. Bir geliştirici, tümü kontrol ettikleri birden fazla modülde çalışıyorsa ve bir yapılandırma dosyasından bir değer okumak için bir UML grafiğini çözmek istemiyorsa. Ayrıca bkz. - bir yapılandırma sistemine sahip diğer PHP çerçevelerinin çoğu. Ne olursa olsun, Magento 2 çekirdek ekibin niyeti o modül yapılandırma ise olduğu bir yere belirtmek gerekir ki, modül başına özel ve özel.
Alan Storm

Ayrıca - (biraz farklı / teğet) Magento'nun arka ucundaki Sistem Yapılandırması bölümü - mevcut bir bölümün yapılandırmasına dayanan bir özellik oluşturma.
Alan Storm

2
@Api ile açıklamalı olmayan herhangi bir api özeldir, yani onu kullanırsanız geriye dönük uyumluluk / api değişikliklerinden siz sorumlu olursunuz. \ Magento \ Framework \ Config \ ReaderInterface \ @api ek açıklamasına sahiptir.
KAndy

0

Bu yazı sırasında, Magento 2'de birleştirilmiş bir yapılandırma ağacını okumak gibi bir standart yok gibi görünüyor. Her modül kendi yapılandırma okuma sınıflarını uygular, bu da her bir geliştiricinin bu birleştirmeyi nasıl istediklerine karar vermesi anlamına gelir. gerçekleşmesi için. Magento bunu yapmak için bazı stok sınıfları sunarken, çekirdek kodlar arasında bile bu sınıfların kullanımı tutarsızdır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.