Clarify XSD for formElements allowed settings #14170
Conversation
In an attempt to resolve #14140, new complex types have been defined for every UI component specified in `ui_settings.xsd` line 49 (valid attribute codes for "formElement"). These complex types only include the `<settings>` child node, along with any grandchildren that pertain specifically to that form element (no `abstractSettings`). Finally, `ui_configuration.xsd` has been updated with a new group holding these complex types, and the corresponding validation for the `<formElements>` tag references this new group rather than the existing, more general group.
I did a bit of code digging but couldn't figure out why the price component definition did not have any valid/configured child nodes for <settings> whatsoever. I decided that the best route would be to add blank groups with the proper labels, so that the actual validation results remain unchanged, but the skeleton now exists for future developers to add valid configuration.
|
@VladimirZaets I completely missed that--thank you! I couldn't figure out why the price component never had any valid |
I'm not sure if the solution proposed in this commit is correct, but I couldn't figure out any more logical way to deal with the validation errors on the Travis CI build. The error follows: 1) Magento\Test\Integrity\Xml\SchemaTest::testXmlFiles Passed: 1881, Failed: 6, Incomplete: 0, Skipped: 0. Data set: /app/code/Magento/Catalog/view/adminhtml/ui_component/category_form.xml Error validating /home/travis/build/magento/magento2/app/code/Magento/Catalog/view/adminhtml/ui_component/category_form.xml against urn:magento:module:Magento_Ui:etc/ui_configuration.xsd Array ( [0] => Element 'fileUploader': This element is not expected. Expected is one of ( hidden, file, input, date, boolean, checkbox, checkboxset, email, select, multiselect ). Line: 168 [1] => Element 'wysiwyg', attribute 'class': The attribute 'class' is not allowed. Line: 206 ) Failed asserting that an array is empty. Element zero in that array is what I am attempting to fix here.
Without this part of the configuration, children of <formElements> nodes can not have their attributes (such as "class") configured.
|
Is there any way to run the Travis CI tests locally, or is pushing up code to my Github branch the only way to check for errors? Alas, the CI build takes a few hours, and I often don't have time during the week to come back and check on my mistakes. |
Again, this error was discovered during the Travis CI build, specifically during validation of /app/code/Magento/Theme/view/adminhtml/ui_component/design_config_form.xml, line 275.
neillrobson
dismissed
VladimirZaets’s stale review
I believe that the issue mentioned about the undeclared type has been resolved with the recent commits. All Travis checks are passing as of the time this comment is being written.
|
Hi @RNanoware , we had the discussion your PR, because it has backward incompatible changes. |
|
I just made a new PR (which can be found here). I don't trust myself trying to manually edit an existing pull request to target a different branch without breaking something. Hope this helps; let me know if there is anything else I can do! |
|
@RNanoware thanks. I close this PR and will start work with PR to the 2.3 branch. |
3 participants
Description
In an attempt to resolve #14140, new complex types have been defined for every UI component specified in
ui_settings.xsdline 49 (valid attribute codes for "formElement"). These complex types only include the<settings>child node, along with any grandchildren that pertain specifically to that form element (noabstractSettings). Finally,ui_configuration.xsdhas been updated with a new group holding these complex types, and the corresponding validation for the<formElements>tag references this new group rather than the existing, more general group.Fixed Issues (if relevant)
Manual testing scenarios
I have not tested these changes due to lack of time, nor am I sure that I have applied the appropriate fix to the task at hand. Please review both the functionality of the changes and the issue that they are intended to fix before merging, and feel free to make changes/a new PR if necessary.