This ticket is repurposed since most of the effort moved to a followup MGNLUI-6253

In this ticket only preparatory code changes were introduced that will be necessary for MGNLUI-6253 fix. The open PR associated with this ticket is for MGNLUI-6253, bb does not allow disassociating it anymore, can be ignored.

Former problem description:

[CURRENT STATUS]: Timebox to 5 points. During the allocated time we need to update the implementation status and choose the eventual strategy. Preferably we should avoid content migration and at the same time not add to much tech debt to the framework.

Steps to reproduce

  # Given form.yaml

1. Open this dialog
2. Add two items
3. Save (items saved as nodes "0", "1")
4. Now to simulate a content saved by the old framework, rename "1" to "00"
5. Open the dialog

Expected results

The second item is loaded with correct values.

Actual results

 
The second item is loaded but it's empty.
If lucky and validators are in place, you can't save the item.
Otherwise the content would be probably lost.
 

Possible ways to mitigate the problem

• Migrate the content is one option. However, there are implications with even unknowables: should potentially the client-side code (in templates) be as well migrated, the output of delivery endpoints might change etc. We could though consider this as part of the migration toll that the customers should account for, just like porting their custom code. We are though in minor-release cycle with 6.2, so this solution is not desirable.
• Alternative proposal: timebox the effort, closely research the cases of remaining transformers and their datastructures. Then try to support them in a similar fashion like we used when introduced the info.magnolia.ui.editor.ByLexicographicallyIndexedChildNodes: provide the necessary configuration options, but keep them in the compatibility artifact from the beginning and keep them forever deprecated.

Development notes

• when working on this we neeed to verify whether we actually have to make sure that the multi-field entry names follow the naming pattern strictly. We do that to ensure that the multi-field only messes with own child nodes named in certain way and never interferes with other nodes, potentially managed by other complex fields (e.g. if multi-field uses the root form node as own root). Is there any use case for such strictness?
• there are still three relevant converters for multi fields that could be used in old fw and have no replacement in new fw, see:
  https://documentation.magnolia-cms.com/display/DOCS62/Magnolia+6+UI+ports+of+5+UI+field+transformer+classes