{"id":787,"date":"2013-05-21T15:30:05","date_gmt":"2013-05-21T20:30:05","guid":{"rendered":"http:\/\/xlinesoft.com\/blog\/?p=787"},"modified":"2026-08-22T17:03:01","modified_gmt":"2026-08-22T22:03:01","slug":"validation-in-phprunner-and-asprunnerpro-applications","status":"publish","type":"post","link":"https:\/\/xlinesoft.com\/blog\/2013\/05\/21\/validation-in-phprunner-and-asprunnerpro-applications\/","title":{"rendered":"Data Validation in PHPRunner: Client-Side and Server-Side Options"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

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

<\/p>\n

1. Built-in validation<\/h2>\n

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.<\/p>\n

Depending on the field and its configuration, you can use built-in validation for requirements such as:<\/p>\n

    \n
  • making a field required;<\/li>\n
  • validating numbers and other expected data types;<\/li>\n
  • checking email addresses and other common formats;<\/li>\n
  • limiting acceptable values according to the field configuration.<\/li>\n<\/ul>\n

    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.<\/p>\n

    2. Validation with regular expressions<\/h2>\n

    Regular expressions are useful when a value must follow a particular format.<\/p>\n

    For example, suppose an internal code must contain exactly three uppercase letters followed by four digits:<\/p>\n

    ^[A-Z]{3}[0-9]{4}$<\/pre>\n
    This would accept values such as:<\/p>\n
    ABC1234<\/pre>\n
    and reject values that do not follow the required structure.<\/p>\n
    Regular expressions work well for structured identifiers, account numbers, reference codes and similar values where the format can be described precisely.<\/p>\n
    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.<\/p>\n
    3. Custom client-side validation<\/h2>\n
    For rules that are not covered by the standard validation options, you can add JavaScript validation to the Add or Edit page.<\/p>\n
    For example, suppose an order has StartDate<\/strong> and EndDate<\/strong> fields and the end date cannot be earlier than the start date.<\/p>\n
    A custom client-side check can compare the two values and display an error before the form is submitted.<\/p>\n
    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.<\/p>\n
    Client-side validation is especially useful for:<\/p>\n
      \n
    • comparing two fields;<\/li>\n
    • checking combinations of values;<\/li>\n
    • providing immediate feedback;<\/li>\n
    • preventing obviously invalid forms from being submitted.<\/li>\n<\/ul>\n
      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.<\/p>\n
      4. Server-side validation before saving<\/h2>\n
      Use the Before record added<\/strong> and Before record updated<\/strong> events when a rule must be enforced before data reaches the database.<\/p>\n
      For example, suppose the Quantity<\/strong> field must always contain a positive value.<\/p>\n
      Before record added:<\/strong><\/p>\n
      \n