Data Validation in PHPRunner: Client-Side and Server-Side Options

Data validation helps prevent incomplete, incorrectly formatted or otherwise invalid data from being saved. PHPRunner provides several ways to validate user input, from built-in field rules to custom JavaScript and server-side validation.

The right approach depends on what you need to check. Simple requirements such as mandatory fields can usually be handled with built-in validation. More complex business rules may require custom code.

A useful rule is to distinguish between user experience and data integrity. Client-side validation gives users immediate feedback, but important rules should also be enforced on the server before data is saved.

1. Built-in validation

For common validation requirements, start with PHPRunner’s built-in field validation settings. They require no custom code and provide immediate feedback while the user is entering data.

Depending on the field and its configuration, you can use built-in validation for requirements such as:

• making a field required;
• validating numbers and other expected data types;
• checking email addresses and other common formats;
• limiting acceptable values according to the field configuration.

Built-in validation should normally be your first choice when it already covers the requirement. Custom code is most useful when the rule is specific to your application.

2. Validation with regular expressions

Regular expressions are useful when a value must follow a particular format.

For example, suppose an internal code must contain exactly three uppercase letters followed by four digits:

^[A-Z]{3}[0-9]{4}$

This would accept values such as:

ABC1234

and reject values that do not follow the required structure.

Regular expressions work well for structured identifiers, account numbers, reference codes and similar values where the format can be described precisely.

Avoid making a regular expression unnecessarily complicated. If the validation rule depends on other fields, database values or application logic, custom validation is usually easier to understand and maintain.

3. Custom client-side validation

For rules that are not covered by the standard validation options, you can add JavaScript validation to the Add or Edit page.

For example, suppose an order has StartDate and EndDate fields and the end date cannot be earlier than the start date.

A custom client-side check can compare the two values and display an error before the form is submitted.

The exact code depends on the controls and data types used on your page, but the important point is that this validation runs in the browser. The user receives feedback immediately and can correct the value without submitting the form first.

Client-side validation is especially useful for:

• comparing two fields;
• checking combinations of values;
• providing immediate feedback;
• preventing obviously invalid forms from being submitted.

However, client-side validation should not be the only place where an important business rule is enforced. Browser-side code can be bypassed, so critical checks should also be performed on the server.

4. Server-side validation before saving

Use the Before record added and Before record updated events when a rule must be enforced before data reaches the database.

For example, suppose the Quantity field must always contain a positive value.

Before record added:

if ($values["Quantity"] <= 0) {
    $message = "Quantity must be greater than zero.";
    return false;
}

return true;
[/php]

The same validation can be added to <strong>Before record updated</strong> if the rule must also apply when existing records are edited.

Returning <strong>false</strong> prevents the record from being saved. The message explains what the user needs to correct.

This type of validation is appropriate for rules that must always be enforced regardless of what happens in the browser.

<h2>5. Validate against existing database data</h2>

Some rules require checking other records in the database.

For example, suppose an application stores an employee code and that code must be unique. Before saving the record, you can query the database to see whether the value already exists.

[php]
$sql = "select EmployeeID from Employees where EmployeeCode = " .
    db_prepare_string($values["EmployeeCode"]);

$rs = DB::Query($sql);
$data = $rs->fetchAssoc();

if ($data) {
    $message = "This employee code is already in use.";
    return false;
}

return true;

For an Edit page, remember that a uniqueness check normally needs to exclude the record currently being edited. Otherwise, the existing value can appear to be a duplicate of itself.

Also consider enforcing truly unique values with a unique constraint or unique index in the database. Application validation can provide a better error message, while the database constraint provides the final protection against duplicates.

6. Validate relationships between fields

Server-side validation is also useful when several fields must be considered together.

For example, suppose a discount cannot exceed the order total:

if ($values["Discount"] > $values["OrderTotal"]) {
    $message = "Discount cannot be greater than the order total.";
    return false;
}

return true;

Rules like this are usually easier to understand as normal code than as complex regular expressions.

The same principle applies to date ranges, minimum and maximum values, status transitions and other business rules involving multiple fields.

7. Client-side or server-side?

In many applications, the best solution is to use both.

Client-side validation is best for immediate feedback. Users can see a problem before submitting the form, which makes the application faster and easier to use.

Server-side validation is best for enforcing rules that must never be bypassed. It is also required when validation depends on database data or other information that is only available on the server.

A typical application might therefore:

1. mark required fields using PHPRunner’s built-in validation;
2. use client-side validation to provide immediate feedback for more complex input;
3. repeat critical business-rule checks in Before record added or Before record updated;
4. use database constraints where the database itself should guarantee data integrity.

Keep validation close to the rule it protects

Not every validation requirement needs custom code. Start with PHPRunner’s built-in options and add custom validation only when the application’s rules require it.

For important data, think in layers. Browser-side validation improves the user experience, server-side validation protects the application logic, and database constraints can provide an additional level of protection for rules that must always hold.

This approach keeps validation easier to understand while making it much harder for invalid data to reach the database.