Magento 2.2では、新しいファイルdefinition.map.xmlが導入されました。
このファイルの目的と目的は何ですか?これはでのschemaMapプロパティの構築に関連しているようですMagento\Ui\Config\Converter
が、GitHubのメモには、このファイルの意図や、その内容が伝えることを実際に説明しているものはありません。
一般的な好奇心以外に、私の主な関心はM2.2で壊れたチュートリアルモジュールにパッチを当てることです。
Magento 2.2では、新しいファイルdefinition.map.xmlが導入されました。
このファイルの目的と目的は何ですか?これはでのschemaMapプロパティの構築に関連しているようですMagento\Ui\Config\Converter
が、GitHubのメモには、このファイルの意図や、その内容が伝えることを実際に説明しているものはありません。
一般的な好奇心以外に、私の主な関心はM2.2で壊れたチュートリアルモジュールにパッチを当てることです。
回答:
私の現在の高レベルの理解は、その目的が(Magento 2.2)UIコンポーネントのノードからそのノードにXMLデータdefinition.map.xml
をマッピングすることであるということです。<settings>
<argument>
編集:この回答を書いた後、Magentoのドキュメントに、ここでのセマンティックの変更に関する追加情報があることがわかりました。
コンテキストについては、UIコンポーネントは<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>
UIコンポーネントに指定された場合、配列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の数文字を1つの構成ファイルに保存します。
ただし、すべてのマッピングがコピーアンドペーストの単純な問題であるとは限りません。たとえば、ボタン構成のマッピングは次のように見えます。
<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>
...そして見かけ上、MagentoのUi/Config
PHP変換コードを通過するという追加の利点があります。
これは、部外者がこれらのファイルの背後にある意図であると認識しているものの大まかな見方にすぎません。実際のMagento開発者は、コードの機能の詳細とこの追加レベルの背後にある動機の両方について、より多くの洞察を提供できるはずです。抽象化の。
編集:Magentoのドキュメントには、実際、これらの変更の背後にある動機を説明するページがあるようです。見て、ここで詳細については。