The purpose of a programming validation model is to enable the development of validations, without forcing the developer to write the same validation code several times. All checks and validations in the code should only be made once, and the code should be public and accessible from all parts of the application (i.e. different components). This means that ordinary interface mechanisms should be used as much as possible.
Validations should always be done in the server, but the client also validates input in the window before data is sent to the server, for example data type and length, and if the attribute is mandatory or not etc. It is preferable to reduce the number of validation errors in the client since the server will only show the first validation error on each save and not the complete list of errors.
There are four different types of validations:
|Validation Type||PL/SQL Method|
|Validation of attributes used inside a class|| Check_Common___,
|Validation of fields for direct client response||Separate methods|
|Validation of foreign keys used from other classes||Exist|
|Validation before removing objects from a class||Check_Delete___|
The following sections will describe the different server validation types, how they work and how they are integrated in the Foundation1 development environment.
Validation of attributes is done in the methods
Check_Update___. These two methods include only specific validation when records are inserted or updated. Validations that are common for both insert and update should be done in
Check_Common___ to avoid duplicated code. This method is called from the other two.
The client calls method
Modify__ with option CHECK to make the validation part without inserting or updating any rows in the database. This option solves situations with error messages, without performing any rollback of transactions, when the client tries to save information.
The example below shows how the base validation methods works. Note that these procedures are automatically generated and they contain only validation generated from the model. Any entity specific validation can be added by overriding the methods. It is also possible to change the validation behavior with different code generation properties.
Another type of validation is to check whether a specific base data value exists within its corresponding logical unit (typical foreign key reference) to ensure database consistency. The standard framework method is named
Exist. The method is public and therefore accessible from all other logical units and is implemented as a stored procedure with any foreign key as input parameters. The algorithm is as follows:
- If the attribute exists, then the procedure
Existwill return to the calling procedure and this procedure continues
- If the attribute does not exist, the procedure
Exist* * will call the system service method
Record_Not_Existin package Error_SYSand this will do the following:
- Fetch a proper language independent error message string from the text database.
- Raise an Oracle error by calling system procedure
raise_application_errorand use specific error string.
- The error will be raised through the call stack to a valid exception handler in Oracle Server.
One typical issue in development of business applications is to decide whether it is possible to remove an entity instance and how the entity will know about references from other entities.
For example, should it be possible to remove a customer if it has "unpaid customer invoices" and the customer status is "active". Business rules like this can be implemented by overriding standard method
Check_Delete___. Complex code should be placed in a separate procedure for this purpose and called from
Check_Delete___ has three purposes:
- Decide if deletion is possible due to the attributes within this entity (like status "active" in the example above)
- Decide if deletion is possible due to the existence of foreign keys and if follow on actions is needed.
- Decide if deletion is possible due to the entity attributes of foreign keys(like "unpaid invoices" in the example above)
There are three ways to handle the deletion of a record if it is referenced from other records:
- Restricted delete
- Cascade delete
- Custom delete
For descriptions about the different delete behaviors and how to use them, see Associations.