In order to create rich client business applications, it is critical to address the data validation requirements.
Data validation is about controlling the kind of data values sent for certain data fields or types. No one would want to allow users to populate stores with incorrect or malicious data. Some validations are implicit based on the expected type of data (e.g., you cannot populate a field of type "date" with string or text values). Other validations are explicit, and hence require to be explicitly defined (e.g., an explicit validation rule can be defined on a field of type "string" in order to accept email address values only).
Data validation can be enforced in the business logic layer of the rich client application. However, this is not reliable enough, since a malicious client can always tamper with the business logic and send unexpected data to the Apstrata database service. This points out the need to be able to enforce validation rules on the server side. This can be done using schemas and/or scripting.
Some validation rules can be defined in the schema itself in a declarative way. Validation rules are defined per field.
The following validations can be set in the schema:
- Min Cardinality
- Max Cardinality
- string (default)
- Regex Expression (regular expressions are mainly used to validate the format of the data such as email format for example)
- Min Value
- Max Value
The validation on the “file” type is not yet implemented.
The below schema example shows how to use these validations.
<schema> <fields> <field name="fieldone"> <validation> <regex>---regex validation---</regex> </validation> </field> <field name="fieldtwo" type="numeric" searchable="true" unique="true"> <validation> <regex>thereg2</regex> <cardinality min="1" max="3"></cardinality> <range min="1" max="3"></range> </validation> </field> </fields> </schema>
More complex validation rules can still be enforced on the server side through the use of scripting.