Résumé
Ma compréhension actuelle de haut niveau est que le but de definition.map.xmlest de mapper les données XML d'un <settings>nœud de composant d'interface utilisateur (Magento 2.2) à ses <argument>nœuds.
Edit : Après avoir écrit cette réponse, j'ai trouvé que la documentation de Magento contient des informations supplémentaires sur les changements sémantiques ici .
Explication
Pour le contexte, les composants de l'interface utilisateur utilisent des <argument>nœuds depuis plus longtemps que <settings>. Plus précisément, dans le view/[area]/ui_component/etc/definition.xmlfichier ou view/[area]/ui_component/[ui_component_name].xmlles fichiers de configuration, la pratique standard consistait à inclure un nœud XML tel que le suivant:
<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>
Cette configuration, si elle est donnée, disons, à un <form>composant d'interface utilisateur, se retrouverait transmise au Formconstructeur ( Magento/Ui/Component/Form.php) de la classe PHP dans le $datatableau. La traduction est assez simple.
Cependant, cette structure n'a pas fourni de contrôle nuancé ou de validation du XML définissant. Les développeurs pouvaient mettre tout ce qu'ils voulaient dans leurs <argument>nœuds en toute impunité (au moins, au niveau de la validation XSD), et ces valeurs étaient transmises directement au code PHP sans beaucoup de transformations.
Pour ajouter un niveau d'abstraction et de validation, Magento a introduit le <settings>nœud. Un autre regard sur un nœud dans 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>
... Une structure qui ressemble beaucoup au vieil <argument>arbre commence à apparaître. La seule différence est, par exemple, lorsque l'on souhaite ajouter un spinner à un formulaire, plutôt que d'utiliser le <argument>style:
<argument name="data" xsi:type="array">
<item name="spinner" xsi:type="string">[My_Spinner_Name]</item>
</argument>
... on pourrait remarquer que la même valeur de configuration est mappée par la ligne <item name="spinner" type="string" xsi:type="xpath">settings/spinner</item>à la syntaxe alternative suivante:
<settings>
<spinner>[My_Spinner_Name]</spinner>
</settings>
À première vue, cela semble être un niveau d'abstraction complètement ridicule, enregistrant quelques caractères de XML dans un fichier de configuration en ajoutant plusieurs lignes à un nouveau fichier de mappage.
Cependant, chaque mappage n'est pas une simple question de copier-coller. Par exemple, il semble que le mappage pour la configuration des boutons:
<item name="buttons" type="buttons" xsi:type="converter">settings/buttons</item>
... est de xsi:type="converter"(plutôt que xpath, comme l'exemple de spinner ci-dessus). Déterminer les conséquences d'une telle déclaration est au-delà de mes capacités, mais l'explorateur de code source intrépide voudra peut-être regarder Magento\Ui\Config\Converter, dans lequel beaucoup de ces nœuds de configuration XML plus complexes ont des classes PHP avec des noms correspondants.
L'effet sur le XML est plus apparent. Alors que l'ancienne syntaxe des définitions de bouton aurait été
<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>
... la nouvelle configuration ressemblerait à:
<settings>
<buttons>
<button name="back" class="Company\Basic\Block\Adminhtml\Slides\BackButton"/>
<button name="save" class="Company\Basic\Block\Adminhtml\Slides\SaveButton"/>
</buttons>
</settings>
... et ont apparemment les avantages supplémentaires de passer par le Ui/Configcode de conversion PHP de Magento .
Ce n'est qu'une vue superficielle de ce qu'un étranger perçoit comme l'intention derrière ces fichiers: je suis sûr qu'un développeur Magento réel serait en mesure de fournir beaucoup plus d'informations à la fois sur les détails fonctionnels du code et sur la motivation derrière ce niveau supplémentaire d'abstraction.
Edit : Il semblerait que la documentation de Magento ait en fait une page décrivant la motivation derrière ces changements. Regardez ici pour plus d'informations.
