[MGNLUI-6190] Refactor dependencies for MGNLUI-6253 - old content not loading completely in multi field Created: 07/Sep/20  Updated: 23/Nov/20  Resolved: 29/Sep/20

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: 6.2.3
Fix Version/s: 6.2.5

Type: Improvement Priority: Neutral
Reporter: Roman Kovařík Assignee: Šimon Demočko
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 1d 1.7h
Original Estimate: Not Specified

Attachments: File form.yaml    
Issue Links:
Issue split
split to MGNLUI-6223 MultiValueSubChildrenNodeTransformer ... Closed
dependency
is depended upon by MGNLUI-5346 Migrate Security app to new framework... Closed
supersession
is superseded by MGNLUI-6253 Allow MultiFields using jcrChildNodeP... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: MultiFields compatibility
Sprint: UI FW 11
Story Points: 5

 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


 Comments   
Comment by Šimon Demočko [ 29/Sep/20 ]

Timebox results were satisfactory, will file a followup for wrapping up of code changes

Generated at Mon Feb 12 09:34:02 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.