Validate Binding Behavior
Last updated
Last updated
The validate binding behavior, as the name suggests, adds the validation behavior to a property binding. In other words, it "mark"s the associated property binding as a target for validation by registering the binding to the validation controller.
This is how the validation controller comes to know of the bindings that need to be validated when validationController.validate() method is called.
You must have noticed plenty examples of the validate binding behavior in the demos so far. For completeness, this can be used as follows.
Note that the binding behavior has three optional arguments: trigger, validation controller, and rules.
This dictates when the validation is performed. The valid values are as follows.
manual: Use the validation controller's validate() method to validate all bindings.
blur: Validate the binding when the binding's target element fires a DOM "blur" event.
focusout: Validate the binding when the target element fires a DOM "focusout" event. This is useful when the actual input is wrapped in a custom element, and the validate binding behavior is used on the custom element. In that case, the blur trigger does not work as the blur event does not bubble. See the difference in action below.
change: Validate the binding when the source property is updated (usually triggered by some change in view).
changeOrBlur: Validate the binding when the binding's target element fires a DOM "blur" event and when the source property is updated.
changeOrFocusout: Validate the binding when the binding's target element fires a DOM "focusout" event and when the source property is updated.
There is an important point to note about the changeOrEVENT triggers. The change-triggered validation is ineffective till the associated property is validated once, either by manually calling ValidationController#validate or by event-triggered (blur or focusout) validation. This prevents showing a validation failure message immediately in case of an incomplete input, which might be the case if validation is triggered for every change.
Note the distinction made between incomplete and invalid input. The event-triggered validation is ineffective until the property is dirty, i.e. any changes were made. This prevents showing a validation failure message when there is a blur or focusout event without changing the property. This behavior delays bugging the user and "reward"s eagerly.
The examples above show an explicit usage of trigger. However, this is an optional value; when used, it overrides the default trigger configured. The default trigger is used for that instance when the value is omitted. The default validation trigger is focusout, although it can be changed using the DefaultTrigger registration customization option.
The binding behavior, by default, registers the binding to the closest (in terms of dependency injection container) available instance of the validation controller. Note that the validation controller instance can be made available for the scope using the newInstanceForScope resolver (refer Injecting a controller instance for more details). If no instance of validation controller is available, it throws an error.
However, an instance of validation can be explicitly bound to the binding behavior, using the positional argument. This is useful when you use multiple instances of validation controllers to perform a different validation set.
In the example below, there are two injected controllers and the property person.age the validationController2 is used. Playing with the example, you can see that the person.age does not get validated by the scoped validation controller instance.