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