The ValueHostConfig object configures one ValueHost and its validators. That object isn't ideal for typing in configurations (although its great if you have to write conversion between your own business logic and Jivs).

The ManagerConfigBuilderBase provides a way to configure through meaningful code. There are actually 2 of these, the builder and the modifier. ValueHostsManagerConfigBuilder is used for the initial configuration passed into ValueHostManager/ValidationManager. ValueHostsManagerConfigModifier is used to modify the configuration in an existing ValueHostManager.

Here are two ways to use it. 1) Without business logic 2) with Business logic.

Without Business Logic

let builder = build(createValidatorServices('client'));
builder.input('Field1', LookupKey.String).requireText();
builder.static('Field2', LookupKey.Date);
builder.input('Field3', LookupKey.String).requireText().regExp(^/\d\d\d\-\d\d\d\d$/);
let vm = new ValidationManager(builder); // consider builder disposed at this point
// later when you need to modify vm:
let modifier = vm.startModifying();
modifier.input('Field3').regExp(null, { enabled: false }); // let's disable the existing validator
modifier.apply(); // consider modifier disposed at this point

With Business Logic using the builder and UI overrides its settings

let builder = build(createValidatorServices('client'));  // 'client' because the config targets the UI
builder.property('Field1', LookupKey.String).requireText({ errorMessage: 'Requires a value'});
builder.static('Field2', LookupKey.Date);
builder.property('Field3', LookupKey.String).requireText().regExp(^/\d\d\d\-\d\d\d\d$/);
builder.startUILayerConfig({ favorUIMessages: true, convertPropertyToInput: true });
// At this point, we've converted PropertyValueHosts to InputValueHosts and discarded
// all error messages that were covered by the TextLocalizerService.
builder.input('Field4', LookupKey.String, { label: 'Phone number', parserLookupKey: 'PhoneNumber' }).requireText(); // ui created this ValueHost
builder.input('Field1', null { label: 'Product name' })
builder.input('Field3', null, { label: 'Product code', parserLookupKey: 'ProductCode' });

let vm = new ValidationManager(builder); // consider builder disposed at this point
// later when you need to modify vm:
let modifier = vm.startModifying();
modifier.input('Field3').regExp(null, { enabled: false }); // let's disable the existing validator
modifier.apply(); // consider modifier disposed at this point

With Business Logic using its own conversion logic and UI overrides its settings

let vmConfig: ValidationManagerConfig = {
services: createValidatorServices('client');
validatorConfigs: []
};
myBusinessLogicToJivsConverter(vmConfig); // expect 'Field1', 'Field2', and 'Field3' to be generated as shown in the previous case
let builder = build(vmConfig);
builder.startUILayerConfig({ favorUIMessages: true, convertPropertyToInput: true });
// At this point, we've converted PropertyValueHosts to InputValueHosts and discarded
// all error messages that were covered by the TextLocalizerService.
builder.input('Field4', LookupKey.String, { label: 'Phone number', parserLookupKey: 'PhoneNumber' }).requireText(); // ui created this ValueHost
builder.input('Field1', null { label: 'Product name' })
builder.input('Field3', null, { label: 'Product code', parserLookupKey: 'ProductCode' });

let vm = new ValidationManager(builder); // consider builder disposed at this point
// later when you need to modify vm:
let modifier = vm.startModifying();
modifier.input('Field3').regExp(null, { enabled: false }); // let's disable the existing validator
modifier.apply(); // consider modifier disposed at this point

Combining a condition from the UI with the conditions from the business logic

This common use case is where the UI wants to add a condition to a Validator that was created by the business logic. Use the combineConditionWith() and replaceConditionWith() functions.

The goal is to preserve the condition from the business logic by using it together with the UI's condition in one of these ways:

  • Make the business logic's condition optional by wrapping it in a WhenCondition.

    // business logic
    builder.input('Field1', LookupKey.String).notNull();
    // UI wants it to look like this:
    builder.input('Field1', LookupKey.String)
    .when(
    (enablerBuilder)=> enablerBuilder.equalToValue('YES', 'Field2'),
    (childBuilder)=> childBuilder.notNull()
    );
    // using the combineConditionWith() function
    builder.input('Field1').combineConditionWith(
    ConditionType.NotNull, // error code
    CombineUsingCondition.When,
    (combiningBuilder)=> combiningBuilder.equalToValue('YES', 'Field2'));
  • All conditions must evaluate as a match using the AllCondition

    // business logic
    builder.input('Field1', LookupKey.String).regexp(/^[A-Z]+$/i);
    // UI wants it to look like this:
    builder.input('Field1', LookupKey.String)
    .all((childrenBuilder)=> childrenBuilder.regexp(/^[A-Z]+$/i).stringLength(10));

    // using the combineConditionWith() function
    builder.input('Field1').combineConditionWith(
    ConditionType.NotNull, // error code
    CombineUsingCondition.All,
    (combiningBuilder)=> combiningBuilder.stringLength(10));
  • Either condition can evaluate as a match using the AnyCondition

  • The UI's condition is a complete replacement for the business logic's condition. // business logic builder.input('Field1', LookupKey.String).notNull(); // UI wants it to look like this: builder.input('Field1', LookupKey.String) .all((childrenBuilder)=> childrenBuilder.requireText()); // because requireText() includes notNull()

    // using the replaceConditionWith() function builder.input('Field1').replaceConditionWith( ConditionType.NotNull, // error code (replacementBuilder)=> replacementBuilder.requireText());


Type Parameters

Hierarchy (view full)

Implements

Constructors

Accessors

Methods

  • Fluent format to create any ValueHostConfig based upon ValidatorsValueHostBaseConfig. This is the start of a fluent series. Extend series with validation rules like "required()". Protected because ValueHostManager does not support InputValueHost. ValidationManager offers a public interface.

    Type Parameters

    Parameters

    • valueHostType: string

      the ValueHostType to configure

    • arg1: string | Partial<TVHConfig>

      either the ValueHost name for a multiparameter use or InputValueConfig for a single parameter use.

    • Optional arg2: null | string | Partial<TVHConfig>

      optional and can be null. The value for ValueHost.dataType or InputValueHostConfig.

    • Optional arg3: Partial<TVHConfig>

      optional. Any additional properties of a InputValueHostConfig.

    Returns FluentValidatorBuilder

    FluentValidatorBuilder for chaining validators to initial InputValueHost

  • Combines a condition with a ValidatorConfig's condition using a rule supplied or callback to let you create a conditionConfig.

    The resulting ValidatorConfig's errorCode will not have changed from the original to ensure it aligns with everything depending on the original error code.

    Parameters

    • destinationOfCondition: ValidatorConfig

      the conditionConfig that you want to combine with the new condition.

    • arg2: CombineUsingCondition | ((combiningBuilder, existingConditionConfig) => void)

      Either of these:

      • Use a function to create a conditionConfig that will replace the existing. You are passed the Builder object, where you can build your new conditions, and the existing conditionConfig, which can be added to a Builder object with the conditionConfig() function.
      • a CombineUsingCondition enum value that specifies how to combine the conditions.
    • Optional arg3: ((combiningBuilder) => void)

      create the condition that you want to combine with the existing condition.

    Returns void

  • Updates the conditionConfig property of destinationOfCondition where the replacement is either a conditionConfig or using a Builder object.

    If it finds the validator with the errorcode specified, it will replace the condition with the existing condition. If not, it logs and throws an error. If the ValueHost is on an earlier override or baseConfig, a new entry is made in the current override, reflecting the same data as earlier, but now with a modified validator. If the ValueHost is on the current override, the existing entry is modified.

    The resulting ValidatorConfig's errorCode will not have changed from the original to ensure it aligns with everything depending on the original error code.

    Parameters

    • destinationOfCondition: ValidatorConfig
    • sourceOfConditionConfig: ConditionConfig | ((replacementBuilder) => void)

      Either of these:

      • use a function to create a conditionConfig that will replace the existing. You are passed the builder, where you can build your new conditions.
      • provide a complete ConditionConfig as the replacement

    Returns void

Generated using TypeDoc v0.25.12