6 Hierarchy to define field validation
The field can be defined for validation in one the following ways:
Table 6-1
| Level | Description | Entry in DIGX_FW_TAXONOMY_DATA_MAP | |
|---|---|---|---|
| ID | Type | ||
| Field Level | This level is used to validate the taxonomy based on the name of the field. It will be applicable to all the fields with same name in the application irrespective of its data type. This validation can be overridden by a class level entry for specific request DTO | Exact name (case-sensitive) of the private member field of the request DTO class. e.g. payeeID, fromDate, name | FIELD |
| Class Level | This level is used to validate the taxonomy based on the complete hierarchical field name starting with fully qualified name of the request DTO. | Fully hierarchical name of the field. e.g. com.ofss.digx.app.dto.finlimit.TransactionalLimitDTO.owner.value | CLASS |
| Complex Field Level | This level is used to validate the fields of complex data type | As defined in the complex data type validator class. | COMPLEX |
Note:
1. While defining the taxonomy in ‘DIGX_FW_TAXONOMY_DATA_MAP’, override the parameters of ‘DIGX_FW_LOCALE_DATA_TYPE’ as per the requirement.
2. If the entry for the field already exists in ‘DIGX_FW_TAXONOMY_DATA_MAP’, do not modify it for specific case. Instead make an entry of the field as per class hierarchy.
3. In class level entry- If the same DTO is used in multiple services and different taxonomy validation is expected for the field, the developer can override this validation by adding service level taxonomy entry. In this case, instead of fully qualified DTO class name, use the fully qualified method name. (i.e. <Fully_qualified_service_class_name>.<method_name>.fieldName).