Package com.smartgwt.client.widgets.form.validator

# Class Validator

java.lang.Object
com.smartgwt.client.core.JsObject
com.smartgwt.client.core.DataClass
com.smartgwt.client.widgets.form.validator.Validator

All Implemented Interfaces:
  `HasHandlers`

Direct Known Subclasses:
  `ContainsValidator`, `CustomValidator`, `DateRangeValidator`, `DoesntContainValidator`, `EqualsValidator`, `FloatPrecisionValidator`, `FloatRangeValidator`, `InSetValidator`, `IntegerRangeValidator`, `IsBooleanValidator`, `IsFloatValidator`, `IsIntegerValidator`, `IsOneOfValidator`, `IsStringValidator`, `LengthRangeValidator`, `MaskValidator`, `MatchesFieldValidator`, `NotEqualValidator`, `NotInSetValidator`, `RegExpValidator`, `RequiredIfValidator`, `StringCountValidator`

public class Validator extends DataClass
A validator describes a check that should be performed on a value the user is trying to save.

Validators are specified for DataSource fields via the `DataSourceField.validators` property and `are executed in the order in which they are defined`. Validators that need not be run on the server can also be specified for a specific `FormItem` or `ListGridField`.

Smart GWT supports a powerful library of `ValidatorTypes` which have identical behavior on both the client and the server.

Beyond this, custom validators can be defined on the client and custom validation logic added on the server. Note that the `regexp` and `mask` validator types are very flexible and can be used to perform virtually any kind of formatting check that doesn't involve some large external dataset.

Custom validators can be reused on the client by adding them to the global validator list, via the `addValidator()` method.

See Also:
  - `ValidatorType`

- ## Field Summary

  ### Fields inherited from class com.smartgwt.client.core.DataClass

  `factoryCreated, factoryProperties`

  ### Fields inherited from class com.smartgwt.client.core.JsObject

  `jsObj`

- ## Constructor Summary

  Constructors
  Constructor
  Description
  `Validator()`
  `Validator(JavaScriptObject jsObj)`

- ## Method Summary

  Modifier and Type
  Method
  Description
  `static void`
  `addValidatorDefinition(String name, Validator validator)`
  Register a new standard validator type for reuse, by name.
  `static void`
  `create()`
  A Validator shouldn't be created directly.
  `AdvancedCriteria`
  `getApplyWhen()`
  Used to create a conditional validator based on criteria.
  `ClientUniquenessCheckCondition`
  `getCheckComponentData()`
  For a validator of type `"isUnique"` in a dataBoundComponent, under what circumstances should uniqueness checking be performed against the component's data set?
  `Boolean`
  `getClientOnly()`
  Indicates this validator runs on the client only.
  `String`
  `getCondition()`
  For a validator that is not a built-in `ValidatorType`, a `Callback`, function, or JavaScript expression to evaluate to see if this validator passes or fails.
  `String[]`
  `getDependentFields()`
  User-defined list of fields on which this validator depends.
  `AdvancedCriteria`
  `getFailWhen()`
  Defines validation purely via criteria: the record is invalid when the criteria match.
  `static Validator`
  `getOrCreateRef(JavaScriptObject jsObj)`
  `AdvancedCriteria`
  `getPassWhen()`
  Defines validation purely via criteria: the record is valid when the criteria match.
  `Integer`
  `getPrecision()`
  For validators of type "floatPrecision", the `precision` attribute specifies the maximum number of decimal places allowed.
  `Boolean`
  `getRoundToPrecision()`
  For validators of type "floatPrecision", when set to true, a value with more decimal places than `precision` will be rounded to the specified precision rather than failing validation.
  `Boolean`
  `getStopIfFalse()`
  Normally, all validators defined for a field will be run `in the order in which they are defined` even if one of the validators has already failed.
  `Boolean`
  `getStopOnError()`
  Indicates that if this validator is not passed, the user should not be allowed to exit the field - focus will be forced back into the field until the error is corrected.
  `ValidatorType`
  `getType()`
  Type of the validator.
  `String`
  `getTypeAsString()`
  Type of the validator.
  `Boolean`
  `getValidateOnChange()`
  If true, validator will be validated when each item's "change" handler is fired as well as when the entire form is submitted or validated.
  `Validator`
  `setApplyWhen(AdvancedCriteria applyWhen)`
  Used to create a conditional validator based on criteria.
  `Validator`
  `setCheckComponentData(ClientUniquenessCheckCondition checkComponentData)`
  For a validator of type `"isUnique"` in a dataBoundComponent, under what circumstances should uniqueness checking be performed against the component's data set?
  `Validator`
  `setClientOnly(Boolean clientOnly)`
  Indicates this validator runs on the client only.
  `Validator`
  `setCondition(String condition)`
  For a validator that is not a built-in `ValidatorType`, a `Callback`, function, or JavaScript expression to evaluate to see if this validator passes or fails.
  `Validator`
  `setDependentFields(String[] dependentFields)`
  User-defined list of fields on which this validator depends.
  `Validator`
  `setErrorMessage(String errorMessage)`
  Text to display if the value does not pass this validation check.
  `Validator`
  `setFailWhen(AdvancedCriteria failWhen)`
  Defines validation purely via criteria: the record is invalid when the criteria match.
  `Validator`
  `setPassWhen(AdvancedCriteria passWhen)`
  Defines validation purely via criteria: the record is valid when the criteria match.
  `Validator`
  `setPrecision(Integer precision)`
  For validators of type "floatPrecision", the `precision` attribute specifies the maximum number of decimal places allowed.
  `Validator`
  `setRoundToPrecision(Boolean roundToPrecision)`
  For validators of type "floatPrecision", when set to true, a value with more decimal places than `precision` will be rounded to the specified precision rather than failing validation.
  `Validator`
  `setStopIfFalse(Boolean stopIfFalse)`
  Normally, all validators defined for a field will be run `in the order in which they are defined` even if one of the validators has already failed.
  `Validator`
  `setStopOnError(Boolean stopOnError)`
  Indicates that if this validator is not passed, the user should not be allowed to exit the field - focus will be forced back into the field until the error is corrected.
  `Validator`
  `setType(ValidatorType type)`
  Type of the validator.
  `Validator`
  `setType(String type)`
  Type of the validator.
  `Validator`
  `setValidateOnChange(Boolean validateOnChange)`
  If true, validator will be validated when each item's "change" handler is fired as well as when the entire form is submitted or validated.

  ### Methods inherited from class com.smartgwt.client.core.DataClass

  `applyFactoryProperties, doAddHandler, fireEvent, getAttribute, getAttributeAsBoolean, getAttributeAsBoolean, getAttributeAsDate, getAttributeAsDouble, getAttributeAsDoubleArray, getAttributeAsElement, getAttributeAsFloat, getAttributeAsInt, getAttributeAsIntArray, getAttributeAsJavaScriptObject, getAttributeAsLong, getAttributeAsMap, getAttributeAsObject, getAttributeAsRecord, getAttributeAsString, getAttributeAsStringArray, getAttributes, getHandlerCount, isFactoryCreated, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttribute, setAttributeAsJavaObject, setFactoryCreated`

  ### Methods inherited from class com.smartgwt.client.core.JsObject

  `equals, getJsObj, hashCode, isCreated, setJavaScriptObject, setJsObj`

  ### Methods inherited from class java.lang.Object

  `clone, finalize, getClass, notify, notifyAll, toString, wait, wait, wait`

- ## Constructor Details

  - ### Validator

    public Validator()

  - ### Validator

    public Validator(JavaScriptObject jsObj)

- ## Method Details

  - ### getOrCreateRef

    public static Validator getOrCreateRef(JavaScriptObject jsObj)

  - ### setApplyWhen

    public Validator setApplyWhen(AdvancedCriteria applyWhen)
    Used to create a conditional validator based on criteria. The criteria defines when the validator applies — evaluated against the current record, `rule\n context`, and (when referencing related DataSources) locally cached data or the server. If the criteria match, the validator is processed; otherwise it is skipped and assumed valid.

    To use an `applyWhen` criteria the form or grid must use a `DataSource`.

    NOTE: `applyWhen` is not supported for "binary" fields.

    ### Server and client use

    Conditional validators are enforced both on the server and on the client-side when defined on a DataSource field as shown in the examples below. Note the `applyWhen` element is treated as a `Criterion`.

          <!-- Conditional requirement: reason is required when
               the order is being cancelled -->
          <field name="reason" type="text">
            <validators>
              <validator type="required">
                <applyWhen fieldName="status" operator="equals"
                           value="Cancelled"/>
              </validator>
            </validators>
          </field>

          <!-- Shipped orders: shipDate must not be before
               orderDate -->
          <field name="shipDate" type="date">
            <validators>
              <validator
                  errorMessage="Ship date cannot be before order date">
                <applyWhen fieldName="status" operator="equals"
                           value="Shipped"/>
                <passWhen fieldName="shipDate"
                          operator="greaterOrEqualField"
                          value="orderDate"/>
              </validator>
            </validators>
          </field>

    The first example shows a conditional `required` validator using `shorthand\n format`. For conditionally required fields, prefer `DataSourceField.requiredWhen` — it is simpler (no validator wrapper), enforced on both client and server, and supports the full ServerDynamicCriteria syntax. Using `applyWhen` with `type:"required"` as shown here still works but introduces complexities around partial-record edits; see the discussion at the end of the `DataSourceField.required` help topic.

    Conditional validators can also be applied to `Component XML` and to DynamicForm or ListGrid fields in Java code as well.

    ### Authentication, request context, and relational references

    Because the type of `applyWhen` is ServerDynamicCriteria, the `fieldName` in criteria can also reference:
    - The current user and request context (`auth.*`, `context.*`) — see ServerDynamicCriteria for which variables are available client-side vs. server-only
    - Fields on related DataSources via `dot notation`, e.g. `Order.status`
    See ServerDynamicCriteria for the full syntax.

    ### Security

    On the server, `applyWhen` criteria are evaluated against the stored database record overlaid with submitted update values. Client-sent `oldValues` are never used, preventing spoofing attacks where a client fabricates field values to bypass validation. For fields not included in the submitted update, the database value is used.

    Note : This is an advanced setting

    Parameters:
      `applyWhen` - New applyWhen value. Default value is null
    Returns:
      `Validator` instance, for chaining setter calls
    See Also:
      - `setPassWhen(com.smartgwt.client.data.AdvancedCriteria)`
      - `setFailWhen(com.smartgwt.client.data.AdvancedCriteria)`

  - ### getApplyWhen

    public AdvancedCriteria getApplyWhen()
    Used to create a conditional validator based on criteria. The criteria defines when the validator applies — evaluated against the current record, `rule\n context`, and (when referencing related DataSources) locally cached data or the server. If the criteria match, the validator is processed; otherwise it is skipped and assumed valid.

    To use an `applyWhen` criteria the form or grid must use a `DataSource`.

    NOTE: `applyWhen` is not supported for "binary" fields.

    ### Server and client use

    Conditional validators are enforced both on the server and on the client-side when defined on a DataSource field as shown in the examples below. Note the `applyWhen` element is treated as a `Criterion`.

          <!-- Conditional requirement: reason is required when
               the order is being cancelled -->
          <field name="reason" type="text">
            <validators>
              <validator type="required">
                <applyWhen fieldName="status" operator="equals"
                           value="Cancelled"/>
              </validator>
            </validators>
          </field>

          <!-- Shipped orders: shipDate must not be before
               orderDate -->
          <field name="shipDate" type="date">
            <validators>
              <validator
                  errorMessage="Ship date cannot be before order date">
                <applyWhen fieldName="status" operator="equals"
                           value="Shipped"/>
                <passWhen fieldName="shipDate"
                          operator="greaterOrEqualField"
                          value="orderDate"/>
              </validator>
            </validators>
          </field>

    The first example shows a conditional `required` validator using `shorthand\n format`. For conditionally required fields, prefer `DataSourceField.requiredWhen` — it is simpler (no validator wrapper), enforced on both client and server, and supports the full ServerDynamicCriteria syntax. Using `applyWhen` with `type:"required"` as shown here still works but introduces complexities around partial-record edits; see the discussion at the end of the `DataSourceField.required` help topic.

    Conditional validators can also be applied to `Component XML` and to DynamicForm or ListGrid fields in Java code as well.

    ### Authentication, request context, and relational references

    Because the type of `applyWhen` is ServerDynamicCriteria, the `fieldName` in criteria can also reference:
    - The current user and request context (`auth.*`, `context.*`) — see ServerDynamicCriteria for which variables are available client-side vs. server-only
    - Fields on related DataSources via `dot notation`, e.g. `Order.status`
    See ServerDynamicCriteria for the full syntax.

    ### Security

    On the server, `applyWhen` criteria are evaluated against the stored database record overlaid with submitted update values. Client-sent `oldValues` are never used, preventing spoofing attacks where a client fabricates field values to bypass validation. For fields not included in the submitted update, the database value is used.
    Returns:
      Current applyWhen value. Default value is null
    See Also:
      - `getPassWhen()`
      - `getFailWhen()`

  - ### setCheckComponentData

    public Validator setCheckComponentData(ClientUniquenessCheckCondition checkComponentData)
    For a validator of type `"isUnique"` in a dataBoundComponent, under what circumstances should uniqueness checking be performed against the component's data set?

    Only applies to validators within a `multiple dataArity` component like a ListGrid.

    Parameters:
      `checkComponentData` - New checkComponentData value. Default value is "both"
    Returns:
      `Validator` instance, for chaining setter calls

  - ### getCheckComponentData

    public ClientUniquenessCheckCondition getCheckComponentData()
    For a validator of type `"isUnique"` in a dataBoundComponent, under what circumstances should uniqueness checking be performed against the component's data set?

    Only applies to validators within a `multiple dataArity` component like a ListGrid.

    Returns:
      Current checkComponentData value. Default value is "both"

  - ### setClientOnly

    public Validator setClientOnly(Boolean clientOnly)
    Indicates this validator runs on the client only.

    Normally, if the server is trying to run validators and finds a validator that it can't execute, for safety reasons validation is considered to have failed. Use this flag to explicitly mark a validator that only needs to run on the client.

    Parameters:
      `clientOnly` - New clientOnly value. Default value is false
    Returns:
      `Validator` instance, for chaining setter calls

  - ### getClientOnly

    public Boolean getClientOnly()
    Indicates this validator runs on the client only.

    Normally, if the server is trying to run validators and finds a validator that it can't execute, for safety reasons validation is considered to have failed. Use this flag to explicitly mark a validator that only needs to run on the client.

    Returns:
      Current clientOnly value. Default value is false

  - ### setCondition

    public Validator setCondition(String condition)
    For a validator that is not a built-in `ValidatorType`, a `Callback`, function, or JavaScript expression to evaluate to see if this validator passes or fails.

    Because the validator declaration itself is passed as a parameter to `condition()`, you can effectively parameterize the validator. For example, to create a validator that checks that the value is after a certain date:

              { type:"custom", afterDate:new Date(),
                condition:"value.getTime() > validator.afterDate.getTime()" }

    Reusable validators, like the above, can be registered as a standard validatorType by calling `addValidator()`.

    Note that, if a field is declared with a builtin `FieldType`, the value passed in will already have been converted to the specified type, if possible.

    For the required parameters, see the documentation for ValidatorConditionCallback.

    Parameters:
      `condition` - New condition value. Default value is null
    Returns:
      `Validator` instance, for chaining setter calls
    See Also:
      - `StringMethod`

  - ### getCondition

    public String getCondition()
    For a validator that is not a built-in `ValidatorType`, a `Callback`, function, or JavaScript expression to evaluate to see if this validator passes or fails.

    Because the validator declaration itself is passed as a parameter to `condition()`, you can effectively parameterize the validator. For example, to create a validator that checks that the value is after a certain date:

              { type:"custom", afterDate:new Date(),
                condition:"value.getTime() > validator.afterDate.getTime()" }

    Reusable validators, like the above, can be registered as a standard validatorType by calling `addValidator()`.

    Note that, if a field is declared with a builtin `FieldType`, the value passed in will already have been converted to the specified type, if possible.

    For the required parameters, see the documentation for ValidatorConditionCallback.

    Returns:
      Current condition value. Default value is null
    See Also:
      - `StringMethod`

  - ### setDependentFields

    public Validator setDependentFields(String[] dependentFields)
    User-defined list of fields on which this validator depends. Primarily used for validators of type "custom" but can also be used to supplement `applyWhen` criteria.

    Note that for validators run on the server, fields required due to `dependentFields` but not present in the `DSRequest.data` of an update because they haven't changed will be filled in from the server DataSource.

    Note : This is an advanced setting

    Parameters:
      `dependentFields` - New dependentFields value. Default value is null
    Returns:
      `Validator` instance, for chaining setter calls
    See Also:
      - `setApplyWhen(com.smartgwt.client.data.AdvancedCriteria)`

  - ### getDependentFields

    public String[] getDependentFields()
    User-defined list of fields on which this validator depends. Primarily used for validators of type "custom" but can also be used to supplement `applyWhen` criteria.

    Note that for validators run on the server, fields required due to `dependentFields` but not present in the `DSRequest.data` of an update because they haven't changed will be filled in from the server DataSource.

    Returns:
      Current dependentFields value. Default value is null
    See Also:
      - `getApplyWhen()`

  - ### setErrorMessage

    public Validator setErrorMessage(String errorMessage)
    Text to display if the value does not pass this validation check.

    If unspecified, default error messages exist for all built-in validators, and a generic message will be used for a custom validator that is not passed.

    Server-side this string evaluates in a Velocity context where the variables $value and $fieldName are available and refer to the supplied value and the field name, respectively. Note that if the validator is intended to run both on the client and server, you shouldn't use these velocity vars as they will not be expanded on the client and the user may then see raw uninterpolated strings.

    Parameters:
      `errorMessage` - New errorMessage value. Default value is null
    Returns:
      `Validator` instance, for chaining setter calls
    See Also:
      - Conditionally Required Example

  - ### setFailWhen

    public Validator setFailWhen(AdvancedCriteria failWhen)
    Defines validation purely via criteria: the record is invalid when the criteria match. If the criteria match, the validator fails and returns `errorMessage`. Inverse of `passWhen`.

    Supports the full ServerDynamicCriteria syntax including references to the current user, operation type, and fields on related DataSources.

    If the outermost criterion omits `fieldName`, it defaults to the field the validator is declared on (same shorthand as `passWhen`).

          <validator errorMessage="Cannot use status 'Cancelled'">
            <failWhen fieldName="status" operator="equals"
                      value="Cancelled"/>
          </validator>

    Note : This is an advanced setting

    Parameters:
      `failWhen` - New failWhen value. Default value is null
    Returns:
      `Validator` instance, for chaining setter calls
    See Also:
      - `setPassWhen(com.smartgwt.client.data.AdvancedCriteria)`
      - `setApplyWhen(com.smartgwt.client.data.AdvancedCriteria)`

  - ### getFailWhen

    public AdvancedCriteria getFailWhen()
    Defines validation purely via criteria: the record is invalid when the criteria match. If the criteria match, the validator fails and returns `errorMessage`. Inverse of `passWhen`.

    Supports the full ServerDynamicCriteria syntax including references to the current user, operation type, and fields on related DataSources.

    If the outermost criterion omits `fieldName`, it defaults to the field the validator is declared on (same shorthand as `passWhen`).

          <validator errorMessage="Cannot use status 'Cancelled'">
            <failWhen fieldName="status" operator="equals"
                      value="Cancelled"/>
          </validator>

    Returns:
      Current failWhen value. Default value is null
    See Also:
      - `getPassWhen()`
      - `getApplyWhen()`

  - ### setPassWhen

    public Validator setPassWhen(AdvancedCriteria passWhen)
    Defines validation purely via criteria: the record is valid when the criteria match. If the criteria do not match, the validator fails and returns `errorMessage`.

    This is an alternative to `serverCondition` that uses declarative criteria instead of scripting. No `type` is required — the criteria ARE the validation logic.

    Supports the full ServerDynamicCriteria syntax including references to the current user, operation type, and fields on related DataSources.

    If the outermost criterion omits `fieldName` (and has no `criteria` sub-array), it defaults to the name of the field the validator is declared on. This allows a compact shorthand:

          <!-- equivalent to fieldName="status" -->
          <field name="status">
            <validators>
              <validator errorMessage="Must be Active">
                <passWhen operator="equals" value="Active"/>
              </validator>
            </validators>
          </field>

          <validator errorMessage="Status must be Pending or Active">
            <passWhen fieldName="status" operator="inSet">
              <value>
                <value>Pending</value>
                <value>Active</value>
              </value>
            </passWhen>
          </validator>

    Note : This is an advanced setting

    Parameters:
      `passWhen` - New passWhen value. Default value is null
    Returns:
      `Validator` instance, for chaining setter calls
    See Also:
      - `setFailWhen(com.smartgwt.client.data.AdvancedCriteria)`
      - `setApplyWhen(com.smartgwt.client.data.AdvancedCriteria)`

  - ### getPassWhen

    public AdvancedCriteria getPassWhen()
    Defines validation purely via criteria: the record is valid when the criteria match. If the criteria do not match, the validator fails and returns `errorMessage`.

    This is an alternative to `serverCondition` that uses declarative criteria instead of scripting. No `type` is required — the criteria ARE the validation logic.

    Supports the full ServerDynamicCriteria syntax including references to the current user, operation type, and fields on related DataSources.

    If the outermost criterion omits `fieldName` (and has no `criteria` sub-array), it defaults to the name of the field the validator is declared on. This allows a compact shorthand:

          <!-- equivalent to fieldName="status" -->
          <field name="status">
            <validators>
              <validator errorMessage="Must be Active">
                <passWhen operator="equals" value="Active"/>
              </validator>
            </validators>
          </field>

          <validator errorMessage="Status must be Pending or Active">
            <passWhen fieldName="status" operator="inSet">
              <value>
                <value>Pending</value>
                <value>Active</value>
              </value>
            </passWhen>
          </validator>

    Returns:
      Current passWhen value. Default value is null
    See Also:
      - `getFailWhen()`
      - `getApplyWhen()`

  - ### setPrecision

    public Validator setPrecision(Integer precision)
    For validators of type "floatPrecision", the `precision` attribute specifies the maximum number of decimal places allowed. If the value has more decimal places than specified and `roundToPrecision` is set, the value will be rounded to the specified precision and validation will pass; otherwise validation fails.
    Parameters:
      `precision` - New precision value. Default value is null
    Returns:
      `Validator` instance, for chaining setter calls
    See Also:
      - `ValidatorType`

  - ### getPrecision

    public Integer getPrecision()
    For validators of type "floatPrecision", the `precision` attribute specifies the maximum number of decimal places allowed. If the value has more decimal places than specified and `roundToPrecision` is set, the value will be rounded to the specified precision and validation will pass; otherwise validation fails.
    Returns:
      Current precision value. Default value is null
    See Also:
      - `ValidatorType`

  - ### setRoundToPrecision

    public Validator setRoundToPrecision(Boolean roundToPrecision)
    For validators of type "floatPrecision", when set to true, a value with more decimal places than `precision` will be rounded to the specified precision rather than failing validation.
    Parameters:
      `roundToPrecision` - New roundToPrecision value. Default value is null
    Returns:
      `Validator` instance, for chaining setter calls
    See Also:
      - `setPrecision(java.lang.Integer)`

  - ### getRoundToPrecision

    public Boolean getRoundToPrecision()
    For validators of type "floatPrecision", when set to true, a value with more decimal places than `precision` will be rounded to the specified precision rather than failing validation.
    Returns:
      Current roundToPrecision value. Default value is null
    See Also:
      - `getPrecision()`

  - ### setStopIfFalse

    public Validator setStopIfFalse(Boolean stopIfFalse)
    Normally, all validators defined for a field will be run `in the order in which they are defined` even if one of the validators has already failed. However, if `stopIfFalse` is set, validation will not proceed beyond this validator if the check fails.

    This is useful to prevent expensive validators from being run unnecessarily, or to allow custom validators that don't need to be robust about handling every conceivable type of value.

    Parameters:
      `stopIfFalse` - New stopIfFalse value. Default value is false
    Returns:
      `Validator` instance, for chaining setter calls

  - ### getStopIfFalse

    public Boolean getStopIfFalse()
    Normally, all validators defined for a field will be run `in the order in which they are defined` even if one of the validators has already failed. However, if `stopIfFalse` is set, validation will not proceed beyond this validator if the check fails.

    This is useful to prevent expensive validators from being run unnecessarily, or to allow custom validators that don't need to be robust about handling every conceivable type of value.

    Returns:
      Current stopIfFalse value. Default value is false

  - ### setStopOnError

    public Validator setStopOnError(Boolean stopOnError)
    Indicates that if this validator is not passed, the user should not be allowed to exit the field - focus will be forced back into the field until the error is corrected.

    This property defaults to `FormItem.stopOnError` if unset.

    Enabling this property also implies `FormItem.validateOnExit` is automatically enabled. If this is a server-based validator, setting this property also implies that `FormItem.synchronousValidation` is forced on.

    Parameters:
      `stopOnError` - New stopOnError value. Default value is null
    Returns:
      `Validator` instance, for chaining setter calls

  - ### getStopOnError

    public Boolean getStopOnError()
    Indicates that if this validator is not passed, the user should not be allowed to exit the field - focus will be forced back into the field until the error is corrected.

    This property defaults to `FormItem.stopOnError` if unset.

    Enabling this property also implies `FormItem.validateOnExit` is automatically enabled. If this is a server-based validator, setting this property also implies that `FormItem.synchronousValidation` is forced on.

    Returns:
      Current stopOnError value. Default value is null

  - ### setType

    public Validator setType(ValidatorType type)
    Type of the validator.

    This can be one of the built-in `ValidatorType`, the string "custom" to define a custom validator, or the string "serverCustom" to define a server-only custom validator.

    Parameters:
      `type` - New type value. Default value is null
    Returns:
      `Validator` instance, for chaining setter calls

  - ### getType

    public ValidatorType getType()
    Type of the validator.

    This can be one of the built-in `ValidatorType`, the string "custom" to define a custom validator, or the string "serverCustom" to define a server-only custom validator.

    Returns:
      Current type value. Default value is null

  - ### setType

    public Validator setType(String type)
    Type of the validator.

    This can be one of the built-in `ValidatorType`, the string "custom" to define a custom validator, or the string "serverCustom" to define a server-only custom validator.

    Parameters:
      `type` - New type value. Default value is null
    Returns:
      `Validator` instance, for chaining setter calls

  - ### getTypeAsString

    public String getTypeAsString()
    Type of the validator.

    This can be one of the built-in `ValidatorType`, the string "custom" to define a custom validator, or the string "serverCustom" to define a server-only custom validator.

    Returns:
      Current type value. Default value is null

  - ### setValidateOnChange

    public Validator setValidateOnChange(Boolean validateOnChange)
    If true, validator will be validated when each item's "change" handler is fired as well as when the entire form is submitted or validated. If false, this validator will not fire on the item's "change" handler.

    Note that this property can also be set at the form/grid or field level; If true at any level and not explicitly false on the validator, the validator will be fired on change - displaying errors and rejecting the change on validation failure.

    Parameters:
      `validateOnChange` - New validateOnChange value. Default value is null
    Returns:
      `Validator` instance, for chaining setter calls

  - ### getValidateOnChange

    public Boolean getValidateOnChange()
    If true, validator will be validated when each item's "change" handler is fired as well as when the entire form is submitted or validated. If false, this validator will not fire on the item's "change" handler.

    Note that this property can also be set at the form/grid or field level; If true at any level and not explicitly false on the validator, the validator will be fired on change - displaying errors and rejecting the change on validation failure.

    Returns:
      Current validateOnChange value. Default value is null

  - ### create

    public static void create()
    A Validator shouldn't be created directly. Instead pass Properties as each Validator in `FormItem.validators` or wherever a Validator is needed.

  - ### addValidatorDefinition

    public static void addValidatorDefinition(String name, Validator validator)
    Register a new standard validator type for reuse, by name. The validator passed in should be of type `ValidatorType.CUSTOM`.

    Any new validator where `setType(String)` is set to the registered name will pick up all properties (error message, condition, etc) from this validator definition.

    Parameters:
      `name` - name under which validator properties will be available
      `validator` - validator containing standard properties for reuse