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.
letbuilder = 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$/); letvm = newValidationManager(builder); // consider builder disposed at this point // later when you need to modify vm: letmodifier = vm.startModifying(); modifier.input('Field3').regExp(null, { enabled:false }); // let's disable the existing validator modifier.apply(); // consider modifier disposed at this point
letbuilder = 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' });
letvm = newValidationManager(builder); // consider builder disposed at this point // later when you need to modify vm: letmodifier = vm.startModifying(); modifier.input('Field3').regExp(null, { enabled:false }); // let's disable the existing validator modifier.apply(); // consider modifier disposed at this point
letvmConfig: ValidationManagerConfig = { services:createValidatorServices('client'); validatorConfigs: [] }; myBusinessLogicToJivsConverter(vmConfig); // expect 'Field1', 'Field2', and 'Field3' to be generated as shown in the previous case letbuilder = 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' });
letvm = newValidationManager(builder); // consider builder disposed at this point // later when you need to modify vm: letmodifier = vm.startModifying(); modifier.input('Field3').regExp(null, { enabled:false }); // let's disable the existing validator modifier.apply(); // consider modifier disposed at this point
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());
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
With Business Logic using the builder and UI overrides its settings
With Business Logic using its own conversion logic and UI overrides its settings
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.
All conditions must evaluate as a match using the AllCondition
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());