Uploaded image for project: 'Magnolia UI'
  1. Magnolia UI
  2. MGNLUI-6190

Refactor dependencies for MGNLUI-6253 - old content not loading completely in multi field

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Done
    • Neutral
    • 6.2.5
    • 6.2.3
    • None
    • None

    Description

      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

      Checklists

        Acceptance criteria

        Attachments

          Issue Links

            Activity

              People

                sdemocko Šimon Demočko
                rkovarik Roman Kovařík
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  Checklists

                    Task DoD

                    Time Tracking

                      Estimated:
                      Original Estimate - Not Specified
                      Not Specified
                      Remaining:
                      Remaining Estimate - Not Specified
                      Not Specified
                      Logged:
                      Time Spent - 1d 1.7h
                      1d 1.7h