Difference between revisions of "Data Validation"

Revision as of 05:29, 5 December 2017

Under Construction

Validation Rules

Validation rules prevent bad data being saved in a table.

Validating data in Lianja allows you to check data whilst it is being entered by the database user and will enable you to not save the data if it breaks any validation rules.

It is easy for an end user to make a mistake when they are entering data or even to leave out important details that must be entered, so we need to check this data when it is being entered into the database.

In an business application its not only users who perform CRUD (Create Read Update Delete) operations on data but also external processes such as loading tariffs, prices etc into tables periodically in batch.

There must be protections in place to prevent data corruption and invalid data being stored in a database.

This is where validation rules come into play.

Validation Rules in the UI

Data Types

Input masks

Validation Expressions

Validation in Custom Delegates

Required/Mandatory input

Cross Table Lookups

Choice Lists

Autosuggestions

Client-Side Validation in Web/Mobile Apps

Writing client-side JavaScript code is made easier by the fact that Lianja has many VFP compatible functions available for you to use. The complete list can be found here.

The Web/Mobile client maintains the state of active records using client-side cursors.

You can get a reference to an existing cursor like this in desktop, web or mobile apps. This is typically how you would inspect the Active record and its fields.

csr  = Lianja.getCursor("customers");

See the Cursor documentation for details of the properties and methods available.

Server-Side Validation in Web/Mobile Apps

There are several ways for client-side JavaScript code to call server-side procedures/functions.

Using Lianja.evaluate()

Seamless Integration using exports.conf

The exports.conf file enables a simplified approach for calling server-side business procedures directly from the JavaScript client.

This is accomplished by defining the libraries, functions and scripting language for the functions in the exports.conf file which can reside in the app and/or the library directory.

Example exports.conf file:

# This is an example exports.conf file
#
# Each line describes a function that will be available directly from JavaScript code in the client
#
# library, function, type
# (source library, name of the function, type: vfp or javascript)
# (php and python will be added later)
#
# or
#
# library, function 
# (implied type of vfp)
#
# or
#
# function 
# (file expected to exist with a .dbo extension)
#
mylib,myfunc1,vfp
myjslib,myfunc2,javascript
myfunc3,vfp
myfunc4

In the Lianja JavaScript Web/Mobile App the server-side functions can be called directly:

// Note that arguments are automatically converted into the correct format for the 
// remote function call and the function call is proxied
// using a synchronous  Lianja.evaluate() call
var result = myfunc1("hello world", 2015, true);
var result2 = myfunc2();
var result3 = myfunc3();

// When calling remote functions with objects as parameters the object is automatically 
// converted to JSON and sent base64 encoded
// This allows you to send and receive complete JSON encoded objects between the 
// client and the server
var result4 = myfunc4( {"name":"barry", "company":"Lianja" });

Validation Rules for Columns

Column Constraints

Validation Rules for Tables

Table Constraints