Magento 2.2: Що таке файл definition.map.xml?

Magento 2.2 представив новий файл, definition.map.xml .
Яка мета та мета цього файлу? Здається, це пов'язано зі створенням властивості schemaMap Magento\Ui\Config\Converter, але жодна з приміток GitHub насправді не пояснює наміри цих файлів або те, що його вміст має на меті передати.

Окрім загальної цікавості, моя головна зацікавленість полягає у випрацюванні модуля підручника, розбитого в M2.2 .

Підсумок

Моє сучасне розуміння на високому рівні полягає в тому, що мета definition.map.xmlполягає у зіставленні даних XML з <settings>вузла (Magento 2.2) компонента інтерфейсу користувача до його <argument>вузлів.

Редагувати : Після написання цієї відповіді я виявив, що документація Magento містить додаткову інформацію про смислові зміни тут .

Пояснення

Для контексту компоненти інтерфейсу користуються <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>компоненту інтерфейсу користувача, буде завершена, перейшла в 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 в одному файлі конфігурації, додаючи кілька рядків до нового файлу відображення.

Однак не кожне відображення є простим питанням копіювання та вставки. Наприклад, схоже, що відображення для налаштування кнопки:

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

... і нібито мають додаткові переваги при проходженні Ui/Configкоду конверсії PHP Magento .

Це лише короткий перегляд того, що стороннє підприємство сприймає за наміром цих файлів: я впевнений, що фактичний розробник Magento міг би набагато більше зрозуміти як функціональні деталі коду, так і мотивацію цього додаткового рівня абстракції.

Редагувати : Схоже, що в документації Magento насправді є сторінка, що описує мотивацію цих змін. Подивіться тут для отримання додаткової інформації.