Zusammenfassung
Mein derzeitiges Verständnis auf hoher Ebene besteht darin, dass der Zweck darin definition.map.xmlbesteht, XML-Daten vom Knoten einer (Magento 2.2) UI-Komponente ihren Knoten zuzuordnen .<settings><argument>
Bearbeiten : Nachdem ich diese Antwort geschrieben hatte, stellte ich fest, dass die Magento-Dokumentation zusätzliche Informationen zu den semantischen Änderungen hier enthält .
Erläuterung
Für den Kontext verwenden UI-Komponenten <argument>Knoten länger als <settings>. Insbesondere bestand die Standardpraxis in der view/[area]/ui_component/etc/definition.xmlDatei oder den view/[area]/ui_component/[ui_component_name].xmlKonfigurationsdateien darin, einen XML-Knoten wie den folgenden einzuschließen:
<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>
Diese Konfiguration würde, wenn sie beispielsweise einer <form>UI-Komponente zugewiesen würde, an den FormKonstruktor ( Magento/Ui/Component/Form.php) der PHP-Klasse im $dataArray übergeben. Die Übersetzung ist ziemlich einfach.
Diese Struktur bot jedoch keine differenzierte Kontrolle oder Validierung des definierenden XML. Entwickler konnten <argument>ungestraft (zumindest auf der XSD-Validierungsebene) alles in ihre Knoten einfügen , was sie wollten , und diese Werte wurden ohne viele Transformationen direkt an den PHP-Code zurückgegeben.
Um eine Abstraktions- und Validierungsebene hinzuzufügen, hat Magento den <settings>Knoten eingeführt. Einen weiteren Blick auf einen Knoten werfen in 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>
... Eine Struktur, die dem alten <argument>Baum sehr ähnlich sieht, beginnt zu erscheinen. Der einzige Unterschied besteht zum Beispiel darin, dass man einem Formular einen Spinner hinzufügen möchte, anstatt den <argument>Stil zu verwenden:
<argument name="data" xsi:type="array">
<item name="spinner" xsi:type="string">[My_Spinner_Name]</item>
</argument>
... man könnte feststellen, dass der gleiche Konfigurationswert von der Zeile <item name="spinner" type="string" xsi:type="xpath">settings/spinner</item>der folgenden alternativen Syntax zugeordnet wird:
<settings>
<spinner>[My_Spinner_Name]</spinner>
</settings>
Auf den ersten Blick scheint dies eine völlig schwierige Abstraktionsebene zu sein, bei der einige XML-Zeichen in einer Konfigurationsdatei gespeichert werden, indem einer neuen Zuordnungsdatei mehrere Zeilen hinzugefügt werden.
Nicht jedes Mapping ist jedoch einfach zu kopieren und einzufügen. Zum Beispiel scheint die Zuordnung für die Schaltflächenkonfiguration:
<item name="buttons" type="buttons" xsi:type="converter">settings/buttons</item>
... ist von xsi:type="converter"(und nicht xpathwie im obigen Spinner-Beispiel). Die Konsequenzen einer solchen Deklaration zu bestimmen, liegt außerhalb meiner Möglichkeiten, aber der unerschrockene Quellcode-Explorer möchte möglicherweise nachsehen Magento\Ui\Config\Converter, in welchen vielen dieser komplexeren XML-Konfigurationsknoten PHP-Klassen mit übereinstimmenden Namen vorhanden sind.
Die Auswirkung auf das XML ist offensichtlicher. Während die alte Syntax für Schaltflächendefinitionen gewesen wäre
<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>
... die neue Konfiguration würde folgendermaßen aussehen:
<settings>
<buttons>
<button name="back" class="Company\Basic\Block\Adminhtml\Slides\BackButton"/>
<button name="save" class="Company\Basic\Block\Adminhtml\Slides\SaveButton"/>
</buttons>
</settings>
... und angeblich die zusätzlichen Vorteile haben, den Ui/ConfigPHP-Konvertierungscode von Magento zu durchlaufen .
Dies ist nur eine flüchtige Ansicht dessen, was ein Außenstehender als die Absicht hinter diesen Dateien wahrnimmt: Ich bin sicher, dass ein tatsächlicher Magento-Entwickler viel mehr Einblick in die funktionalen Details des Codes und die Motivation hinter dieser zusätzlichen Ebene geben kann der Abstraktion.
Bearbeiten : Es sieht so aus, als ob die Magento-Dokumentation tatsächlich eine Seite enthält, die die Motivation hinter diesen Änderungen beschreibt. Weitere Informationen finden Sie hier .
