Interface IConfigMergeServiceBase<TConfig>

The ValidationManagerConfig file may be populated in 2 phases:

• Phase 1: Business Logic provides its ValueHosts and validators. Many aspects of this is not ideal for the UI, including anything localizable, additional validators, and additional enabler conditions.
• Phase 2: UI updates what the Business Logic created, and adds its own ValueHosts and validators. The UI developer will use the ValidationManagerConfigBuilder and fluent syntax to describe their changes.

The IConfigMergeService interface and its class are used by Phase 2. It allows the UI developer to effectively create the same named ValueHosts, but with different characteristics. ConfigMergeService will merge the business logic's configuration but only where it does not lose the goals established, especially in validation rules.

Suppose that Phase 1 creates this (with services passed to it from the UI):

let vmConfig: ValidationManagerConfig = { services: services };
let builder = build(vmConfig);
builder.property('Field1', LookupKey.Number, { label: 'Field 1' }).notNull().greaterThanValue(10);
// same as:
{
  valueHostType: 'Property',
  valueHostName: 'Field1',
  dataType: 'Number',
  label: 'Field 1',
  validatorConfigs: [
    {
      conditionConfig: { conditionType: 'NotNull' }
    },
    {
      conditionConfig: { conditionType: 'GreaterThanValue', value: 10 }
    }
  ]
}
Copy

The UI can use the ConfigMergeService by installing it with the builder.startUILayerConfig() function. From that point on, builder will make it available to the fluent syntax system and fluent will call upon it to address conflicts.

Here is the Phase 2 continuation of the above:

builder.input('Field1', LookupKey.Integer, { label: 'Name', labell10n: 'ProductNameLabel', parserLookupKey: LookupKey.Number }).requireText()
Copy

The resulting valueHostConfig will be (* where changes where made)

{
  valueHostType: 'Input',    //* upscaled from Property
  valueHostName: 'Field1',
  dataType: 'Integer',       //* upscaled from Number
  label: 'Name',     //*
  labell10n: 'ProductNameLabel', //*
  parserLookupKey: 'Number' //*
  validatorConfigs: [
    {
      conditionConfig: { conditionType: 'RequireText' } //* upscaled from NotNull
    },
    {
      conditionConfig: { conditionType: 'GreaterThanValue', value: 10 }
    }
  ]
}
Copy

ConfigMergeService has to deal with several types of Config objects:

• ValueHost (including all subclasses)
• Validator
• Condition (by only replacing it when combineWithRule() or replaceRule() functions where used in the Builder/Modifier)

Its basic behavior is to copy a list of properties from phase 2 over phase 1's object. When phase2 has a property not found in phase1, its just copied. When phase1 and phase2 both have that property (not assigned to undefined), we have to resolve the conflict. The user controls some of those properties, providing rules of: replace, nochange, delete, and a callback.

There are some properties that are strictly controlled by ConfigMergeService like ValueHostName (cannot change it) and ValueHostType (changes automatically for upscaling Property to Input). Also ValidationConfig, ConditionConfig cannot be specified for replacement. But their children can.

Conditions -- the validatorConfig.conditionConfig property -- are a special case. They are resolved by defining the conditions through combineWithRule() or replaceRule() functions where used in the Builder/Modifier.