Ringkasan
Pemahaman tingkat tinggi saya saat ini adalah bahwa tujuannya definition.map.xmladalah untuk memetakan data XML dari <settings>node ( Komponen Magento 2.2) UI ke node-nya <argument>.
Sunting : Setelah menulis jawaban ini, saya menemukan bahwa dokumentasi Magento memiliki informasi tambahan tentang perubahan semantik di sini .
Penjelasan
Untuk konteks, komponen UI telah menggunakan <argument>node untuk waktu yang lebih lama daripada <settings>. Secara khusus, dalam view/[area]/ui_component/etc/definition.xmlfile atau view/[area]/ui_component/[ui_component_name].xmlfile konfigurasi, praktik standar adalah memasukkan simpul XML seperti berikut:
<argument name="data" xsi:type="array">
<item name="js_config" xsi:type="array">
<item name="provider" xsi:type="string">oracle_order_form.oracle_order_form_data_source</item>
</item>
<item name="label" xsi:type="string" translate="true">Company Information</item>
<item name="template" xsi:type="string">templates/form/collapsible</item>
</argument>
Konfigurasi itu, jika diberikan kepada, katakanlah, <form>Komponen UI, akan berakhir diteruskan ke Formkonstruktor kelas PHP ( Magento/Ui/Component/Form.php) dalam $dataarray. Terjemahannya cukup jelas.
Namun, struktur ini tidak memberikan kontrol bernuansa atau validasi XML yang menentukan. Pengembang dapat meletakkan apa pun yang mereka inginkan di <argument>node mereka dengan impunitas (setidaknya, pada tingkat validasi XSD), dan nilai-nilai itu diteruskan kembali ke kode PHP tanpa banyak transformasi.
Untuk menambahkan level abstraksi dan validasi, Magento memperkenalkan <settings>node. Melihat kembali sebuah simpul di definition.map.xml:
<component name="form" include="uiElementSettings">
<schema name="current">
<argument name="data" xsi:type="array">
<item name="layout" xsi:type="array">
<item name="type" type="string" xsi:type="xpath">settings/layout/type</item>
<item name="navContainerName" type="string" xsi:type="xpath">settings/layout/navContainerName</item>
</item>
<item name="config" xsi:type="array">
<item name="selectorPrefix" type="string" xsi:type="xpath">settings/selectorPrefix</item>
<item name="messagesClass" type="string" xsi:type="xpath">settings/messagesClass</item>
<item name="errorClass" type="string" xsi:type="xpath">settings/errorClass</item>
<item name="ajaxSaveType" type="string" xsi:type="xpath">settings/ajaxSaveType</item>
<item name="namespace" type="string" xsi:type="xpath">settings/namespace</item>
<item name="ajaxSave" type="boolean" xsi:type="xpath">settings/ajaxSave</item>
<item name="reloadItem" type="string" xsi:type="xpath">settings/reloadItem</item>
</item>
<item name="buttons" type="buttons" xsi:type="converter">settings/buttons</item>
<item name="spinner" type="string" xsi:type="xpath">settings/spinner</item>
</argument>
</schema>
</component>
... Struktur yang terlihat sangat mirip dengan <argument>pohon tua mulai muncul. Satu-satunya perbedaan adalah, misalnya, ketika seseorang ingin menambahkan spinner ke formulir, daripada menggunakan <argument>gaya:
<argument name="data" xsi:type="array">
<item name="spinner" xsi:type="string">[My_Spinner_Name]</item>
</argument>
... orang dapat memperhatikan bahwa nilai konfigurasi yang sama dipetakan oleh baris <item name="spinner" type="string" xsi:type="xpath">settings/spinner</item>ke sintaks alternatif berikut:
<settings>
<spinner>[My_Spinner_Name]</spinner>
</settings>
Di permukaan, ini tampak seperti tingkat abstraksi yang benar-benar konyol, menyimpan beberapa karakter XML dalam satu file konfigurasi dengan menambahkan beberapa baris ke file pemetaan baru.
Namun, tidak setiap pemetaan adalah masalah sederhana salin dan tempel. Sebagai contoh, tampaknya pemetaan untuk konfigurasi tombol:
<item name="buttons" type="buttons" xsi:type="converter">settings/buttons</item>
... adalah dari xsi:type="converter"(bukan xpath, seperti contoh pemintal di atas). Menentukan konsekuensi dari deklarasi seperti itu di luar kemampuan saya, tetapi penjelajah kode sumber pemberani mungkin ingin melihat Magento\Ui\Config\Converter, di mana banyak dari node konfigurasi XML yang lebih kompleks ini memiliki kelas PHP dengan nama yang cocok.
Efek pada XML lebih jelas. Padahal sintaks lama untuk definisi tombol seharusnya
<argument name="data" xsi:type="array">
<item name="buttons" xsi:type="array">
<item name="back" xsi:type="string">Company\Basic\Block\Adminhtml\Slides\BackButton</item>
<item name="save" xsi:type="string">Company\Basic\Block\Adminhtml\Slides\SaveButton</item>
</item>
</argument>
... konfigurasi baru akan terlihat seperti:
<settings>
<buttons>
<button name="back" class="Company\Basic\Block\Adminhtml\Slides\BackButton"/>
<button name="save" class="Company\Basic\Block\Adminhtml\Slides\SaveButton"/>
</buttons>
</settings>
... dan seolah-olah memiliki manfaat tambahan melewati Ui/Configkode konversi PHP Magento .
Ini hanya pandangan sepintas tentang apa yang orang luar anggap sebagai maksud di balik file-file ini: Saya yakin bahwa pengembang Magento yang sebenarnya akan dapat memberikan lebih banyak wawasan baik rincian fungsional dari kode dan motivasi di balik level tambahan ini. abstraksi.
Sunting : Sepertinya dokumentasi Magento, pada kenyataannya, memiliki halaman yang menggambarkan motivasi di balik perubahan ini. Lihat di sini untuk informasi lebih lanjut.
