Magento 2.2: Co to jest plik definition.map.xml?

Magento 2.2 wprowadził nowy plik, definicja.map.xml .
Jaki jest cel i zamiar tego pliku? Wydaje się, że jest to związane z budowaniem właściwości schemaMap Magento\Ui\Config\Converter, ale żadna z notatek GitHub tak naprawdę nie wyjaśnia zamiaru tych plików ani tego, co ma przekazać.

Oprócz ogólnej ciekawości, moim głównym zainteresowaniem jest załatanie modułu samouczka, który jest zepsuty w M2.2 .

streszczenie

Moje obecne zrozumienie wysokiego poziomu polega na tym, że celem definition.map.xmljest mapowanie danych XML z <settings>węzła komponentu interfejsu użytkownika (Magento 2.2) na jego <argument>węzły.

Edycja : Po napisaniu tej odpowiedzi odkryłem, że dokumentacja Magento zawiera dodatkowe informacje na temat zmian semantycznych tutaj .

Wyjaśnienie

W kontekście komponenty interfejsu użytkownika używają <argument>węzłów od dłuższego czasu <settings>. W szczególności w view/[area]/ui_component/etc/definition.xmlpliku lub view/[area]/ui_component/[ui_component_name].xmlplikach konfiguracyjnych standardową praktyką było dołączanie węzła XML, takiego jak:

<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>

Taka konfiguracja, powiedzmy na przykład <form>UI Component, zostałaby przekazana do konstruktora Formklasy PHP ( Magento/Ui/Component/Form.php) w $datatablicy. Tłumaczenie jest dość proste.

Jednak ta struktura nie zapewniała szczegółowej kontroli ani sprawdzania poprawności definiującego XML. Programiści mogli <argument>bezkarnie umieszczać w swoich węzłach wszystko, co chcieli (przynajmniej na poziomie sprawdzania poprawności XSD), a te wartości były przekazywane bezpośrednio do kodu PHP bez wielu przekształceń.

Aby dodać poziom abstrakcji i weryfikacji, Magento wprowadziło <settings>węzeł. Ponowne spojrzenie na węzeł w 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>Zaczyna pojawiać się struktura, która wygląda bardzo podobnie do starego drzewa. Jedyna różnica polega na przykład na tym, że chce się dodać do formularza pokrętło zamiast używać <argument>stylu:

<argument name="data" xsi:type="array">
    <item name="spinner" xsi:type="string">[My_Spinner_Name]</item>
</argument>

... można zauważyć, że ta sama wartość konfiguracji jest odwzorowana przez linię <item name="spinner" type="string" xsi:type="xpath">settings/spinner</item>na następującą alternatywną składnię:

<settings>
    <spinner>[My_Spinner_Name]</spinner>
</settings>

Na pierwszy rzut oka wydaje się to całkowicie głupim poziomem abstrakcji, zapisującym kilka znaków XML w jednym pliku konfiguracyjnym poprzez dodanie wielu wierszy do nowego pliku mapowania.

Jednak nie każde mapowanie jest prostą kwestią kopiowania i wklejania. Na przykład wydaje się, że mapowanie konfiguracji przycisków:

<item name="buttons" type="buttons" xsi:type="converter">settings/buttons</item>

... jest xsi:type="converter"(a nie xpathjak w powyższym przykładzie przędzarki). Określenie konsekwencji takiej deklaracji jest poza moim zasięgiem, ale nieustraszony eksplorator kodu źródłowego może chcieć przyjrzeć się Magento\Ui\Config\Converter, w którym wiele bardziej złożonych węzłów konfiguracji XML ma klasy PHP o pasujących nazwach.

Wpływ na XML jest bardziej widoczny. Natomiast byłaby stara składnia definicji przycisków

<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>

... nowa konfiguracja wyglądałaby następująco:

<settings>
    <buttons>
        <button name="back" class="Company\Basic\Block\Adminhtml\Slides\BackButton"/>
        <button name="save" class="Company\Basic\Block\Adminhtml\Slides\SaveButton"/>
    </buttons>
</settings>

... i pozornie mają dodatkowe zalety przechodzenia przez Ui/Configkod konwersji PHP Magento .

To tylko pobieżny pogląd na to, co outsider postrzega jako zamiar tych plików: jestem pewien, że prawdziwy programista Magento byłby w stanie zapewnić znacznie więcej wglądu zarówno w szczegóły funkcjonalne kodu, jak i motywację stojącą za tym dodatkowym poziomem abstrakcji.

Edycja : Wygląda na to, że dokumentacja Magento faktycznie zawiera stronę opisującą motywację tych zmian. Zajrzyj tutaj, aby uzyskać więcej informacji.