Joseph Hallenbeck

December 2, 2013

My Favorite PHP Helper Function — A Better Isset()

Filed under: Software Development — Tags: , , — Joseph @ 10:44 am

Flattr this!

My favorite helper function for CodeIgniter is a ridiculously simple function that has an amazing amount of utility. I stole, at least the idea of, this function from LemonStand and it has since made its way into nearly every CMS that I have worked on:

*  Check if $var is set and if not return null or default
*  @param mixed $var The var to check if it is set.
*  @param mixed $default The value to return if var is not set.
function h( &$var, $default = null) {

    return isset( $var ) ? $var: $default;


At first this doesn’t really seem to be doing much, after all at first glance it looks like it is nothing more than a wrapper for isset, but this improves heavily upon isset in two very important ways. First, let’s look at how this function works.

In the function definition we are taking a reference to a variable. Recall, a reference is pointing at the memory, not value, of a variable and so we can actually pass to our helper function a variable that has not yet been initialized. This saves us from receiving a notice that the variable does not exist. Our call to isset thus checks our memory to see if it is actually referencing a variable or nothing at all. If it is referencing an actual variable it returns that variable, otherwise it returns null (our default default) or whatever value has been assigned to $default.

The utility of this is best expressed in handful of examples. The biggest use of this is in a view. Let us look at a view constructed without the use of our helper function:

<h2><?= isset( $title ) ? $title : 'Blog Title' ?></h2>
<p><?= isset( $content ) ? $content : null ?></p>

In a sizable view the above can get quite long and quite cumbersome to maintain. Each call to isset is checking to see if the controller actually passed the value on to the view ( $title or $content ). If we did not do this we would get a notice from PHP. Sometimes this is resolved by programmers by using the error suppression symbal (@), however the notices will still end up in the logs of many frameworks that strictly check for errors. Contrast this with a view using our helper function:

<h1><?= h( $title, 'Blog Title' ) ?></h2>
<p><?= h( $content ) ?></p>

The above is a much, much more concise view that is easier to read and is still a strictly valid snippet of PHP that generates no warnings or notices. Once we start to use this helper function regularly all different kinds of uses come up for it, for example we can use it to see if a model returned a value:

# 1. Longer method without using the helper function
$page = $this->pages->getByURI( $url );
if( ! $page )
    $page = $this->pages->get404();
$this->render( $page );

# 2. With helper function
$page = h( $this->pages->getByURI( $url ), $this->pages->get404() );
$this->render( $page );

The above snippets are fairly simple, but let’s walk through them. In both instances we need to pass some page object on to the render method. An error occurs if it does not get a valid page object so we must check after retrieving a page that it actually exists. In the first snippet we use four lines of code to first get a page by $url (the value of which is set somewhere else). Now if the pages model returns nothing then we enter a conditional statement that retrieves the 404 error page.

However, with the use of our helper function we can shorten the code in half and remove the conditional all together make it a much more readable snippet of code. The first line of the second snippet simply passes the return of the pages model and the get404 method into our helper function which returns the first if it returns something or the latter if it does not. The only downside is the additional load since the 404 page would also need to be loaded concurrent to the current page with each request, but in most cases this is going to be negligible.

Having looked at two different uses for our helper function, we can begin to see that we can get quite a bit out of some very very small functions. If you have your own favorite one-liner functions feel free to share in the comments below.

November 25, 2013

Improving Upon CodeIgniter’s Validation

Filed under: Software Development — Tags: , , , — Joseph @ 9:49 am

Flattr this!

In this article I plan on addressing CodeIgniter’s shortfalls as a framework for validating objects and introduce a method for improving the validator classes re-usability.

When To Validate?

The answer to this question is simple: whenever we are dealing with input. The (incorrect) assumption that CodeIgniter and many web-applications make is that user input comes in the form of GET and POST variables and a considerable amount of effort goes into validating inputs via these routes. However, GET and POST are not the only sources for user input. User input can come via external sources such as tying into a remote API, an RSS feed, or from the database itself. From each of these sources we could get an invalid state. In the case of the remote API or RSS feed this is easy to understand. The API could change, or the RSS feed could be malformed. In the case of the database the issue typically appears when data is stored into the database under one context but is then accessed with a different expectation.

Take for example a database with the following table:

  `id` int(10) NOT NULL AUTO_INCREMENT,  
  `name` varchar(256) NOT NULL,
  `birthdate` DATE NOT NULL,  
PRIMARY KEY (`id`) ) ;

Now say that we inserted a person with name “Bob” and birthdate “1975-01-01.” This passes the validator going into the database, but later on we pull this row from the database and use it to construct a plain PHP object with properties id, name, and birthdate which we pass onto the view and attempt to output the birthdate with the following line:

echo date('Y-m-d', $person->birthdate);

This is going to cause an error. Why? Because the date function is expecting the second parameter to be a UNIX timestamp, but birthdate is already a formatted date string. Now, we could solve this by changing the schema of the database or changing the schema of the person object, but it is important to note that even if we did fix the disparity between the two we would still not fix the issue that it is possible for the person object to exist in an invalid state.

So my answer is to when should validation occur is during object instantiation and setting. The properties of the object should not be able to be set to a value that the object cannot accept. This places validation clearly into the realm of the “M” in “MVC.”

Form Validation in CodeIgniter

CodeIgniter’s documentation offers a form validation class that makes the above mistake very clearly. It can only validate the POST super global and doesn’t really offer much of a solution towards validation of objects themselves. Furthermore, their example controller oddly mixes the issue of object validation, and thus business logic, inside the controller which tends to create in many CI application fairly bloated controllers:

public function index()
  $this->load->helper(array('form', 'url'));

  $this->form_validation->set_rules('username', 'Username', 'callback_username_check');
  $this->form_validation->set_rules('password', 'Password', 'required');
  $this->form_validation->set_rules('passconf', 'Password Confirmation', 'required');
  $this->form_validation->set_rules('email', 'Email', 'required|is_unique[]');

  if ($this->form_validation->run() == FALSE) {
  } else {

I cannot offer a solution towards adapting the validation class to be fully object operating without a heavy rewrite of the class, but we can move this obtuse validation into a distinct model that encapsulates this behavior away from the controller.

Introducing the Abstract Validator Class

We can get the validation logic out of the controller by moving it into a Validator class. We begin with an abstract base class since each form will need their own validator classes:

abstract class Validator extends CI_Model 
  protected $rules = array(); 
  protected $fields = array();

  # Get keys of fields.
  public function getStructure()
    return array_keys( $this->fields );

  # Validate $_POST against the rules and fields.
  public function validate()
    foreach( $this->rules as $key => $rule )
      $this->form_validation->set_rules( $key, $this->fields[$key], $rule );

    return $this->form_validation->run( $this );

We take advantage of the fact that the CI god to access the form_validation object inside the Validator instance to create the validate method which merely sets the validation rules and then runs them. The Validator has two properties $rules and $fields which we will use in sub-classes to provide the CI_Validator rules and fields strings. We can transform the above controller into the following subclass:

class LoginValidator extends Validator
  protected $rules = array(
                       'username' => 'callback_username_check',
                       'password' => 'required',
                       'passconf' => 'required',
                       'email' => 'required|is_unique[]');
  protected $fields = array(
                        'username' => 'User Name',
                        'password' => 'Password',
                        'passconf' => 'Password Confirmation',
                        'email' => 'E-Mail');

  public function username_check( $name )
    return $this->users->check_username( $name );

Here we can see how the rules and fields are used as well as how we can extend the Validator class to add additional unique callback validations. This simplifies the controller significantly:

public function index() { 

  if ( $this->loginvalidator->validate() ) {
  } else {

The business logic is now gone and the controller is back to focusing on what it’s supposed to be doing — load resources and running paths.

November 19, 2013

Building Pecunia – Introduction

Filed under: Software Development — Tags: , , , — Joseph @ 9:49 pm

Flattr this!

What is Pecunia?

I have been keeping my own personal accounts for some time in a progressively growing spreadsheet that after one decade of use, multiple files, and dozens of worksheets. The entire thing is quite a mess. My solution? Build an app for it! Pecunia will be a simple budgeting application designed from the ground up for keeping track of monthly budgets, annual budgets, and keeping a ledger of individual expenses. With a little bit of work, I should be able to turn it into a multi-user application to launch as an extension on for public use as well as an open source repository on Bitbucket.

This also gives me an excuse for a long series of posts going through the steps necessary to take a spread sheet, abstract it’s logic into models, and implement it’s functionality into a useful application.


Pecunia will be built using the following resources:

  • PHP 5.4
  • Apache 2.2
  • MySQL 5.5
  • Silex Laraval 4

Update: January 22, 2014

After some consideration, I am opting away from Silex towards using Laraval 4. It is not that I have suddenly found a dislike for Silex, rather I love working with it, but that I would like to try my hands at the “latest and greatest” to see what the big deal is about and to add another tool to my retinue.

September 23, 2013

CodeIgniter’s God Complex

Filed under: Software Development — Tags: , , , — Joseph @ 9:00 am

Flattr this!

I have worked with Code Igniter almost exclusively for the last nine months. In that time, I have found it to be a massive step ahead over working with some of the major CMS systems on the market (WordPress, I am looking at you). Nevertheless, there remains some major architectural and blind spots that exist in CodeIgniter as a framework. Some of these issues are resolvable (CodeIgniter’s presumption that you would only ever want to validate the POST superglobal), while others are inherent in it’s design. In this series I hope to look at some of these issues that I have found with CodeIgniter, showcase work-arounds where I can, or simply rant where no good solution exists. Today’s topic will be of the latter variety.

The God Object AntiPattern

Lets dip over to WikiPedia for the definition of a God Object:

In object-oriented programming, a god object is an object that knows too much or does too much… a program’s overall functionality is coded into a single “all-knowing” object, which maintains most of the information about the entire program and provides most of the methods for manipulating this data. Because this object holds so much data and requires so many methods, its role in the program becomes god-like (all-encompassing). Instead of program objects communicating amongst themselves directly, the other objects within the program rely on the god object for most of their information and interaction.

The God Object in CodeIgniter

CodeIgniter started as an early MVC framework that has maintained backwards compatibility with PHP5.2. It’s maintainers have insisted on maintaining this compatibility which has limited CI from taking advantage the advances that PHP5.3, 5.4, and 5.5 introduced to the language.

There remains nothing truly wrong with PHP5.2. While 5.3+ offers us many great advantages, a SOLID framework is still possible using the older version. CI’s architectural issues do not stem necessarily from it’s usage of the older version but rather the violation of SOLID principles in archetyping it’s interpretation of MVC.

In CI we have the CI super class (the idea of a super class alone should be a code smell) that is globally available via the get_instance() function. This returns an instance of CI_Controller, our main application controller handling the current request. This instance is our elusive beast. The God Object itself. We’ll call this object CI from here on out.

In any one request there can be only one instance of CI — it is essentially a singleton responsible for:

  1. Loading models
  2. Processing the request
  3. Returning the response

Overloaded Models

Here is where we get into the meat and potatoes.

The CI object begins its life by loading resources, that is it begins by loading various models and libraries and maintaining links to each of them like so:

public function __construct()

This code instantiates an instance of the news model and assigns a reference to news. It then instantiates an instance of events. In this manner every model that comes into existence during request process is held as a reference by the CI object and can be access latter on in the request, e.g.

public function index()
  $data = array();
  $data['articles'] = $this->news->get( 3 );
  $this->load->view( 'news', $data );

Once more, something very peculiar is done during this process. CI not only instantiates an instance of the given model but it also copies these references to every subsequently loaded model.

Thus every object that is loaded in this manner becomes aware of every object that had been loaded up-to that point regardless of whether that object really needed access to the behaviors of those objects. The model becomes unnecessarily bloated and the difficulty of debugging the behaviors of a given model increases. Unintended behaviors might be caused not by the model itself but by the combination of that particular model and the order or selection of previously loaded models.

Examine a Model’s State? No way.

Take for example the simple act of using var_dump to see the state of an object in memory. If we were to var_dump our instance of news we might as well call it a day as news contains a reference to everything that has been loaded into memory for our request. The server will proceed to dump the entirety of our application to the screen for us to wade through!

No Public Property is Safe

A larger issue is the assigning of the references themselves. Since the first act of initiating the model object is to copy CI’s massive registry of references to the model any properties or references set in the model’s constructor is at the mercy of the controller overwriting the model. Take for example, the events model. Let’s say the following was in the constructor:

public function __construct()
  $this->news = new News();

Following substantiation of the events object the Events object CI will immediately overwrite the news property with it’s own instance of the news property. Thus the events model would either need to make the news property private or protected which would generate an error when CI attempts to access it or we would always need to take care to keep our model properties from existing in the same namespace as CI.

I actually ran into a horrible bug where this very thing happened. I had a class named Validator that I loaded in with the controller. I also intended each of my models to load their own instances of the Validator class and to initialize their instances with own unique validation parameters. However, since the controller had already loaded an instance of Validator it immediately overwrote each of my model’s Validator‘s forcing them all to use the same instance of the class. The resolution to this problem was to have to name each instance of Validator something different, thus we had EventValidator, NewsValidator, etc.

February 20, 2012

Properly Seperate Content Images from Layout Using CSS

Filed under: Software Development — Tags: — Joseph @ 9:35 pm

Flattr this!

When I started making websites in the 1990s we had a much smaller set of tools and a lot of websites were what we would today call “static.” A static site was nothing more than a folder of html files that contained both the content and layout of the site. If we wanted to change the layout of our site, we would either need to get new content or go through each individual file and update the layout. 

Today we have CSS which introduced the paradigm of sperating content from layout. A site that applies this principle throughout its implementation will be a site that can easily be “reskined” or “re-templatized” without needing to port the content from the old site. (more…)

March 28, 2011

Automatic Lightbox on WordPress via JavaScript

Filed under: Software Development — Tags: , — Joseph @ 2:37 am

Flattr this!

I dabbling more and more with JavaScript lately. In the past my solutions to most site-related problems has been to write server-side PHP modules to add whatever functionality I needed. Since I started using WordPress to manage my site content, I started finding myself using JavaScript to ease-up on the amount of html that I need to type into my post boxes. Take Lightbox for an example. Lightbox is a pretty amazing piece of JavaScript that easily creates animated slideshows out of a series of image links. I use it on my art and photography pages. The problem with Lightbox? Telling Lightbox to animate a link rather than just link straight to the pictures is very verbose. For example to create this animation:

Ivan Sketch “This ink wash panel from my webcomic ‘Ivan @ the End of the World,’ shows my growing interest in the use of water-based ink washes to depict gradient shading in my works.”

I need to type the following into WordPress:

<a title="This ink wash panel from my webcomic Ivan @ the End of the World, 
          shows my growing interest in the use of water-based ink washes to 
          depict gradient shading in my works."
   href="" >
    <img class="aligncenter" 
         alt="Ivan Panel" width="60%" />

Why so much text? First, Lightbox uses the anchor’s title attribute to generate a caption rather than the image’s alt text. The result is the repetition of the string value for the alt and title attributes. Second, lightbox uses the anchor tag’s href value to direct the browser to load the full resolution image. This allows the image tag to point to a smaller thumbnail picture. Yet in most cases of blogging, the thumbnail is just the original picture reduced to fit into the blog’s div. If this is the case than the href attribute on the anchor is merely replicating the src attribute on the image tag. What we really want, is to shorten the monstrosity above into this:

    <img class="aligncenter" 
         alt="This ink wash panel from my webcomic 'Ivan @ the End of the World,' 
              shows my growing interest in the use of water-based ink washes to 
              depict gradient shading in my works." width="60%">

So much shorter! But how? The solution is in a very simple JavaScript function that I wrote which adds the Lightbox script to all images surrounded by empty anchor tags:

*  lightboxThis is a convenient method for transforming all anchored
*  images in a specified div into lightbox images. To use
*  lightboxThis call it during the onload event in the  tag
*  and pass it the divId for images that should be lightboxed.
*  @param string divId The unique id, all images wrapped in empty anchor
*   tags (&lt;a>&lt;/a>) in the specified div will be transformed into
*   lighbox images. Note: this method uses the img alt attribute
*   to determine the caption and will only work if an alt tag is
*   included in each image, if no caption is desired set the alt
*   attribute to alt=" ".
*  @param optional bool group If this parameter is set to true than
*   lighboxThis will group all images in the specified div into
*   a lighbox group with the name of the unique div id as the
*   group name (e.g. rel="lighbox[divId]")
function lightboxThis(divId, group) {
    var anchors = document.getElementById(divId).getElementsByTagName("a");
    for (i = 0; i &lt; anchors.length; i++) {
        var innerChild = 0;
    innerChild = anchors[i].getElementsByTagName("img");
    if (innerChild[0] && !anchors[i].href) {
        anchors[i].href = innerChild[0].src;
        anchors[i].title = innerChild[0].alt;
        if(!group) { anchors[i].rel = "lightbox"; }
            else { anchors[i].rel = "lightbox["+divId+"]"; }

If you’re interested in implementing this on your own blog simply copy the function into your WordPress theme’s header and surround it with tags. Then you need to add the following to your theme’s <body> tag:

body onload="lightboxThis('blog_area')">

Where ‘blog_area’ is the name for the div id where your blog’s posts reside.

« Newer Posts

Copyright 2011 - 2017 Joseph Hallenbeck Powered by WordPress