For the beginners – Creating quality code – Part 4

Welcome back to the series of articles, where we work our way from the scratch to creating an application with quality code. This is a continuation from the previous article where we finalized the application layer for a ticketing system, In this part, we will create the second layer of code, which we will call process layer. You can follow the links below to read the previous articles of the series.

Part 1

Part 2

Part 3

Step 5 – Creating the Process Layer

In step 4, we were able to finally come up with a nice looking application layer, that allowed us to setup the base skeleton of the ticket management system. We divided the complete functionality of the system into 3 processes, namely login, coder pages and user pages. We are going to take a look at each of these in details now.

Process details: Login

The login process, as the name implies, is extremely simple. It checks whether the user is logged in and if not, shows the login form and validates it to complete the login. Again, similar to when we create the application layer, we will create this process layer. The key point here is to skip any low level details of database/sessions and maintain as clean codebase so that changing the process does not require changing underlying database or session logic. Here’s a first look at the login process code in file ‘login.php’:

function displayLogin()
{
    if (is_form_posted())
    {
        // check if the posted userid and password is valid. if it yes, then find the type of user
        // who just logged in and set those values in session
        if (user_exists($_POST['userid'], $_POST['password']))
        {
            // get usertype and other information and set them into the session
            redirect_to_page('index.php');
        }
    }
    // if code got here, it means either login failed, or we are here first time
    showLoginForm();
}

function showLoginForm()
{
    // type some html and get this done by yourself :)
}

As you can see, we have managed to ‘define’ the intent of our login process, but we have not specified any of the logic related to where the sessions are stored, how soon the session will expire, or from where the user will be authenticated etc. What this does is allows us to remain concentrated on our goal of creating the individual application processes, and describe ‘what the process will do’, and leave all the ‘how the process will do it’ details for later work.

The showLoginForm() function is left blank as an exercise to the user. Even if you are a beginner, this should be fairly trivial, as all it needs to do is print some html to display the login form. If you find any difficulty in this area, leave your comments and I will try to reply to you as soon as possible.

Process details: Coder Pages

Now we come to the most important part of our code, the coder pages. Most of the coding we have done so far had a fairly simple ‘intent’, mostly comprising of one or two conditions. This process is going to be more than that as it will be slightly larger, and we will see how can we code even a larger process like this so that it remains clean and maintains its quality.

Let’s take a look at the code for the file ‘coder_pages.php’

function handleCoderPages()
{
    $page = get_requested_page();
    $file = 'coder_pages/'.$page;
    if (! file_exists())
       $file = 'coder_pages/page_404';
    include($file);
    process_request();
}

That’s It! That’s all there is to the process for coder pages. You must have thought initially that the handleCoderPages() function was going to have a huge switch statement, and will be calling functions all over. However, remember that the application might grow it’s feature list over time, and the above code will make sure you don’t have to come modify it again and again when adding new pages to the application. All you need to do it create a new file in the folder ‘coder_pages’ for the new feature, and add one function into it and you are ready to go! I have already explained why you need to create a function in the file instead of just processing the request as soon as the file is included.

Process details: User Pages

Here is a nice surprise for you. Take a look at the code for the user page process and you will see what I mean.

function handleUserPages()
{
    $page = get_requested_page();
    $file = 'user_pages/'.$page;
    if (! file_exists())
       $file = 'user_pages/page_404';
    include($file);
    process_request();
}

See what I mean? The code for user pages looks identical to the process for coder pages, and the only difference is in the name of the folder being used to store files for each sub module. We will see how can we optimize this code in some other article later. For now, this should be enough to get things going.

Most beginners here will jump on to combining the two files and passing a parameter to the function which will do the magic easily. That is not a good practice at all. Just remember a simple rule: If you write code and find out that it is identical to another piece of code already written, let it be like that. Once you are done finishing your application, not only will you be able to combine the code much easily, you will also be sure that your application is ready and there is very little chance of modification to either peice of code that you are combining.

The leftover is an exercise for the user to cleanup the duplicate coding we have done in the application, while keeping the same logic and functionality within the code.