streszczenie
Moje obecne zrozumienie wysokiego poziomu polega na tym, że celem definition.map.xmljest mapowanie danych XML z <settings>węzła komponentu interfejsu użytkownika (Magento 2.2) na jego <argument>węzły.
Edycja : Po napisaniu tej odpowiedzi odkryłem, że dokumentacja Magento zawiera dodatkowe informacje na temat zmian semantycznych tutaj .
Wyjaśnienie
W kontekście komponenty interfejsu użytkownika używają <argument>węzłów od dłuższego czasu <settings>. W szczególności w view/[area]/ui_component/etc/definition.xmlpliku lub view/[area]/ui_component/[ui_component_name].xmlplikach konfiguracyjnych standardową praktyką było dołączanie węzła XML, takiego jak:
<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>
Taka konfiguracja, powiedzmy na przykład <form>UI Component, zostałaby przekazana do konstruktora Formklasy PHP ( Magento/Ui/Component/Form.php) w $datatablicy. Tłumaczenie jest dość proste.
Jednak ta struktura nie zapewniała szczegółowej kontroli ani sprawdzania poprawności definiującego XML. Programiści mogli <argument>bezkarnie umieszczać w swoich węzłach wszystko, co chcieli (przynajmniej na poziomie sprawdzania poprawności XSD), a te wartości były przekazywane bezpośrednio do kodu PHP bez wielu przekształceń.
Aby dodać poziom abstrakcji i weryfikacji, Magento wprowadziło <settings>węzeł. Ponowne spojrzenie na węzeł w 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>
... <argument>Zaczyna pojawiać się struktura, która wygląda bardzo podobnie do starego drzewa. Jedyna różnica polega na przykład na tym, że chce się dodać do formularza pokrętło zamiast używać <argument>stylu:
<argument name="data" xsi:type="array">
<item name="spinner" xsi:type="string">[My_Spinner_Name]</item>
</argument>
... można zauważyć, że ta sama wartość konfiguracji jest odwzorowana przez linię <item name="spinner" type="string" xsi:type="xpath">settings/spinner</item>na następującą alternatywną składnię:
<settings>
<spinner>[My_Spinner_Name]</spinner>
</settings>
Na pierwszy rzut oka wydaje się to całkowicie głupim poziomem abstrakcji, zapisującym kilka znaków XML w jednym pliku konfiguracyjnym poprzez dodanie wielu wierszy do nowego pliku mapowania.
Jednak nie każde mapowanie jest prostą kwestią kopiowania i wklejania. Na przykład wydaje się, że mapowanie konfiguracji przycisków:
<item name="buttons" type="buttons" xsi:type="converter">settings/buttons</item>
... jest xsi:type="converter"(a nie xpathjak w powyższym przykładzie przędzarki). Określenie konsekwencji takiej deklaracji jest poza moim zasięgiem, ale nieustraszony eksplorator kodu źródłowego może chcieć przyjrzeć się Magento\Ui\Config\Converter, w którym wiele bardziej złożonych węzłów konfiguracji XML ma klasy PHP o pasujących nazwach.
Wpływ na XML jest bardziej widoczny. Natomiast byłaby stara składnia definicji przycisków
<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>
... nowa konfiguracja wyglądałaby następująco:
<settings>
<buttons>
<button name="back" class="Company\Basic\Block\Adminhtml\Slides\BackButton"/>
<button name="save" class="Company\Basic\Block\Adminhtml\Slides\SaveButton"/>
</buttons>
</settings>
... i pozornie mają dodatkowe zalety przechodzenia przez Ui/Configkod konwersji PHP Magento .
To tylko pobieżny pogląd na to, co outsider postrzega jako zamiar tych plików: jestem pewien, że prawdziwy programista Magento byłby w stanie zapewnić znacznie więcej wglądu zarówno w szczegóły funkcjonalne kodu, jak i motywację stojącą za tym dodatkowym poziomem abstrakcji.
Edycja : Wygląda na to, że dokumentacja Magento faktycznie zawiera stronę opisującą motywację tych zmian. Zajrzyj tutaj, aby uzyskać więcej informacji.
