Sommario
La mia attuale comprensione di alto livello è che lo scopo di definition.map.xml
è mappare i dati XML da un <settings>
nodo del componente UI (Magento 2.2) ai suoi <argument>
nodi.
Modifica : dopo aver scritto questa risposta, ho scoperto che la documentazione di Magento contiene ulteriori informazioni sulle modifiche semantiche qui .
Spiegazione
Per il contesto, i componenti dell'interfaccia utente utilizzano i <argument>
nodi da più tempo di <settings>
. In particolare, nel view/[area]/ui_component/etc/definition.xml
file o nei file di view/[area]/ui_component/[ui_component_name].xml
configurazione, la pratica standard era quella di includere un nodo XML come il seguente:
<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>
Quella configurazione, se data, per esempio, a un <form>
componente dell'interfaccia utente, sarebbe finita nel Form
costruttore della classe PHP ( Magento/Ui/Component/Form.php
) $data
nell'array. La traduzione è abbastanza semplice.
Tuttavia, questa struttura non ha fornito controllo o convalida sfumati dell'XML di definizione. Gli sviluppatori hanno potuto mettere <argument>
impunemente ciò che volevano nei loro nodi (almeno, a livello di validazione XSD), e quei valori sono stati passati al codice PHP senza molte trasformazioni.
Per aggiungere un livello di astrazione e validazione, Magento ha introdotto il <settings>
nodo. Dando un'altra occhiata a un nodo 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>
... Una struttura che assomiglia molto al vecchio <argument>
albero inizia ad apparire. L'unica differenza è, ad esempio, quando si desidera aggiungere un filatore a un modulo, anziché utilizzare lo <argument>
stile:
<argument name="data" xsi:type="array">
<item name="spinner" xsi:type="string">[My_Spinner_Name]</item>
</argument>
... si potrebbe notare che lo stesso valore di configurazione è mappato dalla linea <item name="spinner" type="string" xsi:type="xpath">settings/spinner</item>
alla seguente sintassi alternativa:
<settings>
<spinner>[My_Spinner_Name]</spinner>
</settings>
A prima vista, questo sembra un livello di astrazione completamente fatuo, che salva alcuni caratteri di XML in un file di configurazione aggiungendo più righe a un nuovo file di mappatura.
Tuttavia, non tutte le mappature sono una semplice questione di copia e incolla. Ad esempio, sembra che il mapping per la configurazione dei pulsanti:
<item name="buttons" type="buttons" xsi:type="converter">settings/buttons</item>
... è di xsi:type="converter"
(piuttosto che xpath
, come nell'esempio di spinner sopra). Determinare le conseguenze di una simile dichiarazione va oltre la mia capacità, ma l'intrepido esploratore di codice sorgente potrebbe voler esaminare Magento\Ui\Config\Converter
, in cui molti di questi nodi di configurazione XML più complessi hanno classi PHP con nomi corrispondenti.
L'effetto sull'XML è più evidente. Considerando che la vecchia sintassi per le definizioni dei pulsanti sarebbe stata
<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 nuova configurazione sarebbe simile a:
<settings>
<buttons>
<button name="back" class="Company\Basic\Block\Adminhtml\Slides\BackButton"/>
<button name="save" class="Company\Basic\Block\Adminhtml\Slides\SaveButton"/>
</buttons>
</settings>
... e apparentemente hanno i vantaggi aggiuntivi di passare attraverso il Ui/Config
codice di conversione PHP di Magento .
Questa è solo una visione sommaria di ciò che un estraneo percepisce come l'intento dietro questi file: sono sicuro che un vero sviluppatore Magento sarebbe in grado di fornire molte più informazioni sia sui dettagli funzionali del codice sia sulla motivazione dietro questo livello aggiuntivo di astrazione.
Modifica : sembra che la documentazione di Magento abbia, in effetti, una pagina che descriva la motivazione dietro questi cambiamenti. Guarda qui per maggiori informazioni.