Support extension to modify widget configurations, including type & property names

[bluemodus-mwills]

Motivation

This is related to recent work (#239), which allows translating widget property values from the format supported by a legacy or custom selector to values supported by a native XbyK selector -- so valuable, thank you!

But, the powerful extensibility provided for content types in #241 which allows reshaping a content model, inspired taking it even further.

When migrating customers from KX13 to XbyK, some customers really need the ability to consolidate their widgets (similar to consolidating content types as described in #241). Some customers have a lot of redundant widgets that have been developed over time and consolidating them to a smaller set of flexible widgets would save them money during a migration, and it would help them have much better experience after migrating to XbyK.

Here's a real-world example:	Legacy KX13 widgets	Desired XbyK widgets
CallToActionHorizontalWidget CallToActionVerticalWidget DualCTAWidget	FeatureWidget
FeaturedCards FeaturedPagesWidget PageListWidget NavigablePagesWidget	FeatureListWidget
PageSpotlightWidget HeadingBannerWidgetController CalloutBannerWidget HeadingBannerWidget	BannerWidget

This means we need a way to map widget types & property definitions in page builder configurations from an old set of widgets to a new set of widgets.

For example, we would need the ability to transform a widget configuration like this:

{
  "identifier": "69878422-7c10-42d6-b4a2-3fa67c8d5775",
  "type": "Acme.Web.Widgets.CallToActionHorizontalWidget",
  "variants": [
    {
      "identifier": "f0adfb3d-730c-4cc2-a5bd-1a21bb1898c6",
      "properties": {
        "selectedNodeGuid": "1ca20119-ef87-4cfc-8183-7bcb9b9d054a",
        "hideDescription": false
      }
    }
  ]
}

To a configuration like this during the migration of page builder data:

{
  "identifier": "69878422-7c10-42d6-b4a2-3fa67c8d5775",
  "type": "Acme.Web.Widgets.FeatureWidget",
  "variants": [
    {
      "identifier": "f0adfb3d-730c-4cc2-a5bd-1a21bb1898c6",
      "properties": {
        "selectedFeatures": [
          {
              "identifier": "1ca20119-ef87-4cfc-8183-7bcb9b9d054a"
          }
        ]
        "hideDescription": false,
        "layout": "horizontal"
      }
    }
  ]
}

Notice, it requires changing the type name, property names, and even inserting new widget values. It also reflects the ability to transform values using the work done on #239.

Proposed solution

The ideal solution would look similar to the class-mapping extension provided for #241. See sample: ClassMappingSample.cs .

It would allow extension code to inspect the whole configuration for a widget, and map the configuration to what is needed for a new widget.

[tkrch]

Hi @bluemodus-mwills, i will look into it

[bluemodus-gfuller]

Hi @tkrch, I see that you are starting to look into that feature, which would be awesome for a project I am working on here at BlueModus. I just wanted to reiterate what @bluemodus-mwills said regarding how helpful this would be. I have a migration that I am starting next month, for a client that has moved from Kentico 11 to 12 to 13 and now to X by K. Having the ability to transform widget data during the migration process would be fantastic for them from a budget and functionality perspective, helping them clean up some data/content modeling in the process of the migration would be fantastic. Thanks for starting to look at this item for us!

[twozero6]

Hi @tkrch and @akfakmot, by any chance, do you have a rough idea when this feature might be released?

[tkrch]

Hi @twozero6, support was already released in #286 (forgot to close this issue) FYI: @bluemodus-gfuller / @bluemodus-mwills