Adventures in Keyframes and Code

I don’t normally write a post unless I’m specifically publishing code, but I wanted to write a brief post about Code Igniter as it’s the best damn thing I’ve discovered since jQuery!

Overview

If you haven’t heard of it already, CodeIgniter is a rapid application-development framework for PHP that uses the Model-View-Controller pattern to separate the presentation, logic and data from each other whilst building your web application.

What this means in practice is that instead of building one large linear PHP file that…

1. Contains swathes of PHP in the head to filter user input (logic), then
2. Gets results from a database (data) and does something meaningful with them, then finally
3. Outputs the HTML (presentation) and continues to escape in and out of PHP during the process

…you end up working on many different smaller files that do one task only, with which the framework pieces together for you to deliver finished web pages.

However, before I delve into MVC, I want to touch upon CodeIgniters excellent class library.

A excellent and fully-integrated set of Library classes

The primary reason I started using CodeIgniter in the first place, is that it provides an incredibly robust and integrated set of classes to handle everything web-app related, from database classes, to session classes, to file uploading and email.

Had it not been for the fact that you have to use them within the overall CodeIgniter structure, I may well have gone off and carried on the way I was going, with logic at the top of my pages, and presentation at the bottom.

However, in order to actually use them, you have to accept you’ll start coding within the CodeIgniter framework, and things will never be the same again…

An intelligent and modular approach to building web applications

The vast majority of what you do within CodeIgniter will be written within class files, that will fall under one of the three MVC areas:

1. Controllers - classes responsible for making overall decisions, such as deciding what task is being undertaken in response to user-input, as well as loading supporting classes and logic to get the job done. Controllers are the first step in processing a task, and outputting a web page.

   It helps to think of controllers and their methods as the “folder” and “page” structure of a site. For example a “Home Controller” might have an “index” function would handle loading the home page, whilst a “Messaging Controller” and might have a “List” and “Compose” methods would handle listing messages, composing new messages, etc.

   Both these methods would take high-level decisions about the task in hand, offloading the drudgery of the tasks to other elements, such as…

2. Models - classes responsible for everything “data” related, such as read and writing from databases, storing representations of said data, configuration, etc.

   In practice, what this means is that a Controller would never read or write data directly, it would hand all responsibility for that to a Model, and would just make calls such as “get the last 10 unread messages”. The model would do the grunt-work, leaving the Controller to get on with more important things.

3. Views - static or dynamic files that are read by CodeIgniter, populated with data, and are output to the user. Views are analogous with the final page output you’d see in procedural PHP programming.

   A view file need not be an entire web page, it could just be a segment, such as a sidebar, a form, a graph, a header, or a footer. By combining views, you have a lot of power with regards to the output of the final page, as well as a really flexible way to store individual representations of data.

   For example, depending on user input, you could load either a Table View or a Graph View that would be populated by the Model data. Inside the view you’d have written code that would receive Model data and would know what to do with it.

The benefit of this approach is that it’s much easier and quicker to build and maintain your site, as everything’s modular, and can be loaded and swapped out according to the task at hand (and no more huge sprawling pages).

There aren’t really that many downsides to this approach, but it can be a little tricky sometimes, as due to the way CodeIgniter works behind teh scenes, you don’t work with a traditional one-to-one file / page structure, but once you’re used to it, you’ll never want to go back.