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.xml
và 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 @api
phươ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.xml
tệ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\Filesystem
trô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.xml
trong 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.