Magento 2: Các nhà phát triển mô-đun nên đọc các tệp cấu hình của riêng họ như thế nào


20

Kịch bản: Tôi là một nhà phát triển mô-đun Magento 2. Tôi muốn tạo một tập tin cấu hình trong app/etc. Tôi muốn tập tin này được "phạm vi" theo khu vực

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

Trong Magento 1 tôi chỉ cần tạo config.xmlvà tiếp tục theo cách của mình. Phạm vi khu vực đã xảy ra trong chính tệp XML. Tuy nhiên, Magento 2 tiếp cận điều này rất khác

Trong Magento 2, tôi nên tạo tệp lớp nào để đọc các tệp cấu hình có phạm vi này. Không rõ từ nguồn Magento 2, cách "đúng" để làm điều này là gì. Mã lõi có nhiều cách tiếp cận và không có cách nào trong số chúng được đánh dấu bằng một @apiphương thức. Điều này gây khó khăn cho việc biết cách tiến hành với nhiệm vụ nhà phát triển mô-đun phổ biến này. Là một tác dụng phụ thứ cấp, nó cũng gây khó khăn cho việc biết nhà phát triển mô-đun Magento nên đọc như thế nào từ các tệp cấu hình cốt lõi.

Một mặt, có vẻ như "điều đúng" cần làm là tạo một đối tượng đọc hệ thống tệp. Ví dụ: Magento dường như tải import.xmltệp bằng cách sau

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

Lớp cơ sở Magento\Framework\Config\Reader\Filesystemtrông giống như nó có mã để giải quyết phạm vi khu vực.

Tuy nhiên, một số tệp cấu hình Magento dường như tránh mẫu này. Trong khi có người đọc cho các tệp này ( event.xmltrong ví dụ này)

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

Ngoài ra còn có các lớp "dữ liệu phạm vi" sử dụng các đầu đọc này.

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

Điều này làm cho có vẻ như các lớp trình đọc phạm vi là những gì một nhà phát triển mô-đun nên tạo. Nhưng không phải tất cả các tập tin cấu hình đều có các trình đọc phạm vi.

Có một con đường rõ ràng cho các nhà phát triển mô-đun Magento 2 đi theo không? Hay đây chỉ là thứ mà các nhà phát triển mô-đun Magento 2 nên tiếp cận theo cách riêng của họ, và kết quả là sự hỗn loạn / không chuẩn cấu hình-tải chỉ là chi phí cho việc kinh doanh?

Các tài liệu chính thức làm một công việc tốt bao gồm một số các lớp học có sẵn, nhưng không có gì mà hòa giải thực tế không có hướng dẫn rõ ràng trên đó thực hiện cụ thể chúng ta đang giả sử để sử dụng, hoặc nếu kỳ vọng là mỗi mô-đun quyết định làm thế nào để làm điều này trên nó sở hữu.


Tôi nghĩ rằng điều này có thể giúp: magento.stackexchange.com/q/51915/146
Marius

Bạn đã xem PR này bởi @vinai github.com/magento/magento2/pull/1410 chưa? Tôi nghĩ rằng nếu bạn không có yêu cầu đặc biệt, bạn có thể cuộn tệp cấu hình của riêng mình chỉ bằng các loại ảo.
Kristof tại Fooman

Câu trả lời:


4

Để tạo loại cấu hình mới, nhà phát triển mô-đun nên tạo một lớp loại cấu hình sẽ được sử dụng bởi các máy khách cấu hình.

Để làm cho các lớp loại này đơn giản nhất có thể, tất cả hành vi đọc tệp cấu hình và dữ liệu bộ đệm được chuyển sang \Magento\Framework\Config\DataInterfacehai triển khai có thể sử dụng lại:

  • \Magento\Framework\Config\Data - đối với các loại cấu hình chỉ có ý nghĩa được tải trong một phạm vi (chỉ có eav_attribut.xml trong toàn cầu)
  • \Magento\Framework\Config\Data\Scoped - đối với các loại cấu hình có thể được tải trên các phạm vi khác nhau (event.xml - toàn cầu và từng khu vực)

Mỗi loại cấu hình được cho là có Config\DataInterfaceđối tượng được cấu hình sẵn . Cấu hình có thể được thực hiện bằng Kiểu ảo hoặc với kế thừa.

Mặc dù về mặt kỹ thuật, nhà phát triển mô-đun có thể kế thừa kiểu cấu hình của họ từ Config\DataInterfacetriển khai, nhưng không nên mở rộng từ các lớp cốt lõi. Luôn luôn tốt hơn để sử dụng thành phần.

Bây giờ \Magento\Framework\Config\DataData\Scopedchỉ làm bộ nhớ đệm và ủy nhiệm đọc cấu hình \Magento\Framework\Config\ReaderInterface. ReaderInterfaceđược cho là cung cấp cấu hình hợp lệ theo định dạng của mảng PHP cho phạm vi được yêu cầu (nếu cấu hình nằm trong phạm vi). ReaderInterfaceCó thể thực hiện nhiều triển khai (ví dụ: đọc cấu hình từ DB) nhưng Magento chỉ gửi một trình đọc chung : \Magento\Framework\Config\Reader\Filesystem.

\Magento\Framework\Config\Reader\Filesystem thực hiện tất cả các hoạt động cần thiết để đọc tệp từ hệ thống tệp mô-đun: đọc tệp, hợp nhất và xác thực.

Mỗi Config\DataInterfaceđược cho là có cấu hình riêng biệt của Config\ReaderInterface. Như bất kỳ trường hợp nào trong hệ thống, trình đọc cụ thể có thể được cấu hình bằng Kiểu ảo hoặc với tính kế thừa. Tài liệu Magento Mô tả tất cả các Filesystemphụ thuộc.

Mọi phần tử trong chuỗi này là tùy chọn (ngoại trừ chính Lớp Loại cấu hình) và có thể được thay thế bằng cách triển khai cụ thể hơn.


1

Có vẻ như tài liệu chính thức có câu trả lời cho câu hỏi của bạn.


1
Cảm ơn bạn đã trả lời, nhưng tôi không chắc tài liệu đó trả lời câu hỏi của tôi. Nó liệt kê một số giao diện (hữu ích, +1 cho điều đó) có sẵn, nhưng không dung hòa được thực tế không có triển khai cụ thể nào của các giao diện đó ( Magento\Framework\Config\DataMagento\Framework\App\Config) không được đánh dấu bằng @api. Nếu chỉ còn lại tài liệu đó, tôi sẽ giả định rằng, là một nhà phát triển mô-đun, không có hệ thống tiêu chuẩn để tạo và đọc các tệp cấu hình, và tôi có thể làm bất cứ điều gì tôi muốn. Điều đó có vẻ không đúng.
Alan Storm

Bạn có thể mô tả các trường hợp khi bạn cần đọc cấu hình cho một số mô-đun khác? Đối với tôi đọc cấu hình là api riêng của mô-đun.
KAndy

Nếu một nhà phát triển muốn đóng góp cho Magento core. Nếu nhà phát triển làm việc trên nhiều mô-đun, không phải tất cả các mô-đun mà họ kiểm soát và không muốn gỡ rối biểu đồ UML để đọc giá trị từ tệp cấu hình. Xem thêm - hầu hết các khung PHP khác có hệ thống cấu hình. Bất kể, nếu ý định của nhóm nòng cốt Magento 2 là cấu hình mô-đun riêng tư và tùy chỉnh cho mỗi mô-đun, điều đó cần được nêu ở đâu đó.
Alan Storm

Đồng thời - (hơi khác / tiếp tuyến) phần Cấu hình hệ thống trong phần phụ trợ của Magento - xây dựng một tính năng dựa trên cấu hình của phần hiện có.
Alan Storm

2
Bất kỳ api nào không được chú thích với @api đều có nghĩa là nếu bạn sử dụng nó thì bạn phải chịu trách nhiệm cho sự tương thích ngược / api thay đổi các vấn đề. \ Magento \ Framework \ Config \ ReaderInterface có chú thích \ @api.
KAndy

0

Tại thời điểm viết bài này, dường như không có một tiêu chuẩn nào về việc đọc cây cấu hình được hợp nhất trong Magento 2. Mỗi mô-đun thực hiện các lớp đọc cấu hình riêng của nó, điều đó có nghĩa là tùy thuộc vào mỗi nhà phát triển quyết định cách họ muốn hợp nhất này xảy ra. Trong khi Magento cung cấp một số lớp chứng khoán để làm điều này, ngay cả trong số các mã cốt lõi, việc sử dụng các lớp này không nhất quán.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.