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___, Check_Insert___, Check_Update___ |
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_Insert___
and 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 New__
or 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:
Exist
will
return to the calling procedure and this procedure continues
Exist
will call the system service method Record_Not_Exist
in
package Error_SYS and this will do the following:
raise_application_error
and use specific error string.
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___
.
The procedure Check_Delete___
has
three purposes:
There are three ways to handle the deletion of a record if it is referenced from other records:
For descriptions about the different delete behaviors and how to use them, see Associations.