Introduction

This is the second part of the series “Building a PHP 5 form processor.” Welcome back. In the first article, I demonstrated how to programmatically construct online forms, in conjunction with the implementation of basic client-side validation. For this reason, I used some extensible PHP 5 classes. This turns the whole form generation process into a straightforward task, which comes in very handy when at least rough client-side verification is first performed on user input, and then server-side validation is applied before processing the data in some way.

The benefits of having a bunch of classes that do the hard work for constructing web forms rests on the ease of rendering form elements and building their proper layout. You need only use some lines of readable code; you do not need to deal specifically with the form’s (X)HTML markup or JavaScript functions responsible for performing data validation. This situation introduces a greater level of abstraction when building forms, something nearly impossible to achieve with traditional form development methods.

However, at the time of writing this series, I established that server-side validation would be an important part of the generic form processor package. Keeping this idea in mind, the second part of this series will be directed to developing a PHP 5 form verification class, which can be easily extended and improved either by modifying its existing checking methods or adding additional ones, in order to meet the requirements of a given web application.

Hopefully, by the end of this tutorial, you’ll have the general guidelines for how to build a form validating class, by utilizing some PHP built-in introspection functions, along with the functionality of regular expressions.

Want to know more about developing the form “validator” module? Right, stick with me and start reading!

Basic server-side validation: the barebones of a PHP 5 form validation class

Before any attempt to write the form “validator” class, first allow me to explain the driving logic hidden behind its structure. Essentially, the class will expose some basic methods for validating form data, ranging from checking for empty fields to more complex data validation, such as verifying email addresses. In addition, I’ll provide the class with the ability to validate alphabetic and alphanumeric data, float and integer values, and finally whether data is within a specific range of values. Of course, since these methods are only a small piece of the data validation terrain, you can write your own checking methods and extend the capabilities of the class, so it can be used in production environments.

Now that you know how the class will work, take a look at its structure:

class formValidator{
    private $errors=array();
    public function __construct(){}
    // validate empty field
    public function validateEmpty
($field,$errorMessage,$min=4,$max=32){
    }
    // validate integer field
    public function validateInt($field,$errorMessage){
    }
    // validate numeric field
    public function validateNumber($field,$errorMessage){
    }
    // validate if field is within a range
    public function validateRange
($field,$errorMessage,$min=1,$max=99){
    }
    // validate alphabetic field
    public function validateAlphabetic($field,$errorMessage){
    }
    // validate alphanumeric field
    public function validateAlphanum($field,$errorMessage){
    }
    // validate email
    public function validateEmail($field,$errorMessage){
    }
    // check for errors
    public function checkErrors(){
    }
    // return errors
    public function displayErrors(){
    }
}

As you can see, the structure of the above class shows how it will operate. Originally, the class will expose only one private property, $errors, defined by default as an array structure. As you may have guessed, this property will store the error messages corresponding to each offending field that doesn’t meet the validation rules. Aside from this property, I’ve defined the constructor as an empty method (certainly, you may want to completely remove it from the class). Eventually, it might be tasked with some initializing process, so I’ll keep it that way for now.

With reference to the validation methods in question, all of them will accept basically two arguments: the name of the form field to be verified, along with the appropriate error message to be displayed. As I said earlier, I’ve defined a few methods for validating empty values, integers, alphanumeric data and so forth, but the versatility of the class allows you to easily add more methods, such a those aimed at checking for URLs, IP addresses, postal codes, and so on.

Having described the data checking methods originally exposed by the class, there are a couple of methods that remain to be discussed. The first one, “checkErrors()” will be responsible for iterating over the $errors array, determining the existence (or not) of offending form fields. Finally, the “displayErrors()”, as it suggests, will return all the error messages stored in the $errors array to be properly displayed.

At this stage, I’m sure you can imagine at least the basic logic that will implement the corresponding validation methods, so it’s time to leap forward and explicitly define the signatures for each of them.