Migrate Coral UI 2 Multifield to Coral UI 3 Multifield along with existing data migration

bilala23933647

24-02-2020

Dear Community Members,

I want to replace the existing multifield(/libs/granite/ui/components/foundation/form/multifield) with the newer one(/libs/granite/ui/components/coral/foundation/form/multifield). The existing multifield is storing content in object format:

bilala23933647_0-1582540352012.png

I want to convert this existing multi-field JSON data to nodes data. So there are two things involved, one being the usage/introduction of new multifield and second the data migration.

Any help/suggestion is highly appreciated.

Thanks, Bilal.

@ahmedmusallam @Arun_Patidar @Jörg_Hoh 

Accepted Solutions (1)

Accepted Solutions (1)

Arun_Patidar

MVP

24-02-2020

Change the dialog multifield resource type in order to convert coral2 to coral3.

The Challenging part is the content migration, which can be handled by creating a custom utility to convert JSON into nodes

e.g.

https://github.com/arunpatidar02/aem63app-repo/blob/master/java/MultifieldConvertCoral2to3Servlet.ja...

 

Answers (1)

Answers (1)

ahmedmusallam

24-02-2020

This is an interesting topic, I have not implemented a solution for this, but if I did, here are my 2 cents:

Some assumptions to start with:
1. The JSON structure is the same for every instance of your component that's already authored
2. You already use a Sling Model or Use class to get data from JSON

My suggested solution:
1. Rewrite your dialog to use CoralUI3 multifield
2. Rewrite the backing Sling model/Use class to use the nodestore instead of JSON. You should NOT need to change the component HTL or the Sling model/Use class API, only the internal code by which it retrieves the values (to get them from child nodes instead of JSON).
3. write an ACS Commons MCP  or Groovy Script to convert your JSON to a Node Structure for every instance of your component. The node structure must match that which is generated by the CoralUI3 multifield in step 1.

In theory, this would not really need to be verified for every component instance, because you have not changed the Java API for your class or the HTL for your component. Only the internal code. You do, however, need to test sensible authoring scenarios based on your dialog and how complex it is.

Note*: an MCP has the advantage of reporting and error logging for every single component instance, if you write it to do so. You could also write a verification script, that runs after your other script to verify the changes it made. This ensures everything was saved properly and that your repo is consistent.

Note2*: You don't really need to delete the JSON, it can stay there just in case there are issues with the conversion or you need to roll back. When you are 100% sure things are good, you can write a script to remove the JSON.