Резюме
В настоящее время я понимаю, что цель definition.map.xmlсостоит в том, чтобы отобразить данные XML из <settings>узла (Magento 2.2) компонента пользовательского интерфейса в его <argument>узлы.
Изменить : После написания этого ответа я обнаружил, что документация Magento содержит дополнительную информацию о семантических изменениях здесь .
объяснение
Для контекста, компоненты пользовательского интерфейса используют <argument>узлы в течение более длительного времени, чем <settings>. В частности, в view/[area]/ui_component/etc/definition.xmlфайле или view/[area]/ui_component/[ui_component_name].xmlконфигурационных файлах стандартной практикой было включение узла XML, такого как следующее:
<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>
Эта конфигурация, если она будет, скажем, для <form>компонента пользовательского интерфейса, в итоге будет передана в Formконструктор класса PHP ( Magento/Ui/Component/Form.php) в $dataмассиве. Перевод довольно прост.
Однако эта структура не обеспечивала нюансированный контроль или проверку определяющего XML. Разработчики могут <argument>безнаказанно помещать в свои узлы все, что они хотят (по крайней мере, на уровне проверки XSD), и эти значения передаются обратно в код PHP без большого количества преобразований.
Чтобы добавить уровень абстракции и проверки, Magento представил этот <settings>узел. Еще раз взглянем на узел в 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>дерево, начинает появляться. Единственное отличие состоит, например, в том, что когда кто-то хочет добавить спиннер в форму, а не использовать <argument>стиль:
<argument name="data" xsi:type="array">
<item name="spinner" xsi:type="string">[My_Spinner_Name]</item>
</argument>
... можно заметить, что это же значение конфигурации отображается строкой <item name="spinner" type="string" xsi:type="xpath">settings/spinner</item>в следующем альтернативном синтаксисе:
<settings>
<spinner>[My_Spinner_Name]</spinner>
</settings>
На первый взгляд, это кажется совершенно бессмысленным уровнем абстракции: сохранение нескольких символов XML в одном файле конфигурации путем добавления нескольких строк в новый файл отображения.
Однако не каждое сопоставление является простым вопросом копирования и вставки. Например, кажется, что отображение для конфигурации кнопки:
<item name="buttons" type="buttons" xsi:type="converter">settings/buttons</item>
... имеет xsi:type="converter"(а не xpath, как в примере с блесной выше). Определить последствия такого объявления мне не по силам, но, возможно, захочет разобраться с бесстрашным исследователем исходного кода Magento\Ui\Config\Converter, в котором многие из этих более сложных узлов конфигурации XML имеют классы PHP с совпадающими именами.
Влияние на XML является более очевидным. В то время как старый синтаксис для определений кнопок был бы
<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>
... новая конфигурация будет выглядеть так:
<settings>
<buttons>
<button name="back" class="Company\Basic\Block\Adminhtml\Slides\BackButton"/>
<button name="save" class="Company\Basic\Block\Adminhtml\Slides\SaveButton"/>
</buttons>
</settings>
... и якобы имеют дополнительные преимущества прохождения Ui/ConfigPHP-кода конвертации Magento .
Это лишь поверхностный взгляд на то, что посторонний воспринимает как цель этих файлов: я уверен, что настоящий разработчик Magento сможет предоставить гораздо больше информации как о функциональных деталях кода, так и о мотивации этого дополнительного уровня. абстракции.
Редактировать : похоже, что документация Magento действительно имеет страницу, описывающую мотивы этих изменений. Смотрите здесь для получения дополнительной информации.
