UI component definition.map.xml overlooks XSD-valid nodes

[neillrobson]

Preconditions

The issue was discovered in Magento 2.2.2 EE, but looks like it still exists in the 2.2-develop branch of this repository.

Steps to reproduce

1. Create and configure a new UI form component with the following XML definition:

<form xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Ui:etc/ui_configuration.xsd">
  <!-- Include standard <argument>, <settings>, <dataSource> to create minimal form. -->
  <fieldset name="billing">
    <field name="shippingMethod" formElement="select">
      <formElements>
        <select>
          <settings>
            <options class="Magento\Shipping\Model\Config\Source\Allmethods" />
            <label>Shipping Method</label>
          </settings>
        </select>
      </formElements>
    </field>
  </fieldset>
</form>

Expected result

1. The XML should validate with the provided XSD files. (It does.)
2. When viewing the form in the browser, a dropdown select box with the label "Shipping Method" should be shown and populated with the values defined in the Allmethods class.

OR

1. The XML should not validate with the provided XSD files, because the parser will not read the configuration correctly.

Actual result

1. The XML validates.
2. The dropdown select box is populated correctly, but the label is not shown.

However, the following code does display the label in the generated markup:

<form xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Ui:etc/ui_configuration.xsd">
  <!-- Include standard <argument>, <settings>, <dataSource> to create minimal form. -->
  <fieldset name="billing">
    <field name="shippingMethod" formElement="select">
      <settings>
        <label>Shipping Method</label>
      </settings>
      <formElements>
        <select>
          <settings>
            <options class="Magento\Shipping\Model\Config\Source\Allmethods" />
          </settings>
        </select>
      </formElements>
    </field>
  </fieldset>
</form>

The issue seems to be how definition.map.xml is written, specifically around line 285 and 787. Settings such as <label>, which are common to many UI components, are read only from a top-level <settings> node, while component-specific settings such as <options> are read from the appropriate <settings> descendent of <formElements>.

This constraint/decision is perfectly understandable, but it is not represented in the corresponding XSD (see line 271 of ui_configuration.xsd, and the corresponding formElements group). Any child from the abstractSettings group (found here) is allowed (valid) within the <settings> nodes that are descendents of <formElements>, but none of them are read by the configuration reader because they aren't specified in definition.map.xml.

Potential Solutions

Depending on the architectural desires of the Magento team, this miscommunication could be fixed in a few ways:

1. Adding the appropriate xpath mappings for abstractSettings within every component-specific settings mapping.
2. Clarifying/constraining the XSD files to ensure that abstractSettings are only placed in top-level <settings> nodes, and component-specific settings remain isolated.

In short, the new UI component semantics function properly, but permit certain undefined behaviors that should be clarified in both the code itself and in documentation.

[VladimirZaets]

Hi, @RNanoware.
The better solution for fix this issue is to change XSD schema for validating cases when common fields properties are placed inside formElement.

Firstly, we should have the same lists of elements that we can use as formElement because for now, they are different.

formElements list inside ui_configuration.xsd and formElements list inside ui_settings.xsd

The valid list is in the ui_settings.xsd, so we should delete redundant elements from ui_configuration.

[ishakhsuvarov]

Hi @RNanoware
Would you like to submit a Pull Request with a fix for this problem? It will speed up delivery in the scope of future patch releases.

[neillrobson]

I would certainly be glad to put together a patch for this issue. I may not get around to it immediately due to my schedule, so if anyone else wants to grab it, they can also feel free!

[ishakhsuvarov]

@RNanoware Thanks!

[magento-engcom-team]

@RNanoware, thank you for your report.
We've acknowledged the issue and added to our backlog.