About Jamie on Software

Jamie on Software is Jamie Rumbelow's online journal. An opinionated, charismatic teenager's views on web development, business, programming, education, technology and journalism.

Sparkplugs

We build ExpressionEngine and MojoMotor add-ons to help web professionals build better sites.

http://getsparkplugs.com/

Tags
Tweets
Feeds
We Love
Powered by Squarespace
Saturday
Jan072012

Syntax Sugar #5 - A Quick CodeIgniter Caching Helper Function

Caching your data in CodeIgniter? Good. You should be.

I use memcached lots. CI has a fantastic caching driver built in (as of 2.0). Normally, the code you'll write looks like this:

$accounts = $this->cache->memcached->get('user.' . $user_id . '.accounts');

if (!$accounts)
{
    $accounts = $this->db->where('user_id', $user_id)->get('accounts')->results();
    $this->cache->memcached->save('user.' . $user_id . '.accounts', $accounts);
}

$this->load->view('accounts/index', array( 'accounts' => $accounts ));

However this quickly becomes repetitive, boring and cluttering. With a bit of PHP5.3 magic, we can create a really nice little caching helper function that cleans this code up in no time:

function cache($key, $data) {
    $CI =& get_instance();
    $cache = $CI->cache->memcached->get($key);

    if (!$cache) {
        // There's been a miss, so run our data function and store it
        $cache = $data($CI);
        $CI->cache->memcached->save($key, $cache);
    }

    return $cache;
}

Now, our cluttered caching code becomes a commendable concoction of coding culinary craft:

$accounts = cache('user.' . $user_id . '.accounts', function(&$ci){
    return $ci->db->where('user_id', $user_id)->get('accounts')->results();
});

The anonymous method you pass through will only be executed if the cache misses (i.e. there's no data under that key, or it has expired). It will be saved into the cache and return. Delicious.

Monday
Dec262011

CodeIgniter View Presenters

Whenever building applications with CodeIgniter, I always try my best to follow the Model-View-Controller design pattern as much as possible. MVC tells us that views are the presentational filter of the model's data. Over the course of an application's development, it can be very common for views to grow and accumulate cruft. I find that presenters can be a really sleek way of hiding presentational logic away in a class.

Let's look at a simple view that displays some information about a user's bank account:

<div id="account">
    <h1><?= $this->bank->get($account->bank_id)->name ?> - <?= $account->title ?></h1>

    <p class="information">
        <strong>Name:</strong> <?php if ($account->name): ?><?= $account->name ?><?php else: ?>N/A<?php endif; ?><br />
        <strong>Number:</strong> <?php if ($account->number): ?><?= $account->number ?><?php else: ?>N/A<?php endif; ?><br />
        <strong>Sort Code:</strong> <?php if ($account->sort_code): ?><?= substr($account->sort_code, 0, 2) . "-" . substr($account->sort_code, 2, 2) . "-" . substr($account->sort_code, 4, 2) ?><?php else: ?>N/A<?php endif; ?>
    </p>

    <p class="balances">
        <strong>Total Balance:</strong> <?php if ($account->total_balance): ?><?= "&pound;" . number_format($account->total_balance) ?><?php else: ?>N/A<?php endif; ?>
        <strong>Available Balance:</strong> <?php if ($account->available_balance): ?><?= "&pound;" . number_format($account->available_balance) ?><?php else: ?>N/A<?php endif; ?>
    </p>

    <p class="statements">
        <?php if ($this->statements->get_by('account_id', $account->id)): ?>
            <?= anchor('/statements/' . $account->id, 'View Statements') ?>
        <?php else: ?>
            Statements Not Currently Available
        <?php endif; ?>
    </p>
</div>

This is a rather typical view; it's displaying bits of content from an object, checking for a value's existence and pulling in bits from other database tables. It's fine, but it's all a bit messy, and we're duplicating a fair bit of code. Ideally, we want our view to look something like this:

<div id="account">
    <h1><?= $account->title() ?></h1>

    <p class="information">
        <strong>Name:</strong> <?= $account->name() ?><br />
        <strong>Number:</strong> <?= $account->number() ?><br />
        <strong>Sort Code:</strong> <?= $account->sort_code() ?>
    </p>

    <p class="balances">
        <strong>Total Balance:</strong> <?= $account->total_balance() ?>
        <strong>Available Balance:</strong> <?= $account->available_balance() ?>
    </p>

    <p class="statements"><?= $account->statements_link() ?></p>
</div>

This clears up our view considerably and removes a bunch of the duplication. It also strips out as much logic as possible from the views, and can make for some very succinct code.

We're going to create an application/presenters directory, and inside there an account_presenter.php file. This file will contain the presenter class for our account object. Let's start by extracting the title:

<?php

class Account_Presenter {

    public function __construct($account) {
        $this->account = $account;
        $this->ci =& get_instance();
    }

    public function title() {
        return $this->ci->bank->get($this->account->bank_id)->name . "-" . $account->title;
    }
}

We make sure that we can access the CodeIgniter superobject in $this->ci and the account object that we're presenting in $this->account. We can then port the logic that was previously in the view into a title() method.

We can now go ahead and tidy up the information section:

public function name() {
    return $this->account->name ?: "N/A";
}

public function number() {
    return $this->account->number ?: "N/A";
}

public function sort_code() {
    if ($sc = $this->account->sort_code) {
        return substr($sc, 0, 2) . "-" . substr($sc, 2, 2) . "-" . substr($sc, 4, 2);
    } else {
        return "N/A";
    }
}

Similarly, we can tidy up the balances section:

public function total_balance() {
    return ($this->account->total_balance) ? "&pound;" . number_format($this->account->total_balance) : "N/A";
}

public function available_balance() {
    return ($this->account->available_balance) ? "&pound;" . number_format($this->account->available_balance) : "N/A";
}

And finally, the statements link:

public function statements_link() {
    if ($this->ci->statements->get_by('account_id', $this->account->id)) {
        return anchor('/statements/' . $this->account->id, 'View Statements');
    } else {
        return "Statements Not Currently Available";
    }
}

Fantastic. Finally, in our controller, we need to pass through an instance of the presenter rather than the account object itself.

public function show($account_id) {
    $account = $this->account->get($account_id);
    $this->data['account'] = new Account_Presenter($account);

    $this->load->view('account/show', $this->data);
}

...and don't forget to load the presenter at the top of your controller:

require_once APPPATH . 'presenters/account_presenter.php';

...and we are done!

As I'm sure you can see, using presenters allows you to tidy up your views in a really object-oriented way. It'd be great to hear your thoughts about presenters and whether or not you plan on using them.

Thursday
Nov172011

On Smoking

I've just published the first of a new weekly column I'll be writing for PostDesk. This week I talk about smoking. I think it's really interesting.

And lots of people think I'm an idiot.

http://postdesk.com/blog/whats-wrong-with-smoking

Monday
Nov072011

On Commercialising a Community at .net magazine

I've just had an article published in .net magazine, and I'd absolutely love it if you could read it. It's an opinion piece on why you should take advantage of communities and make a shedload of cash.

Teenage developer Jamie Rumbelow is all for open source but argues that creating a side business surrounding a community can actually help it grow and flourish.

Read it over on .net.

Saturday
Nov052011

Getting to know ExpressionEngine 2's config file - Part 3

This is the belated finale in the trilogy of articles I'm writing about how to customise your ExpressionEngine config.php file to allow for a much more dynamic and customisable ExpressionEngine install.

In Part 1, we looked at the basics, why and how to use the config file most effectively and we built a simple example. In Part 2, we extended our config file to allow for multiple servers without changing any values. Today, in Part 3, we'll look at tidying up our config file and we'll take a look at some of the extensive hidden configuration variables.

Let's take a look at our config file so far:

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');

/* Dynamic Configuration
-------------------------------------------------------------------*/
$ext        = ($_SERVER['SERVER_ADDR'] == '127.0.0.1') ? ‘.local’ : ‘.com’;
$base_url   = $base_url = ((isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == "on") ? "https" : "http");
$base_url .= "://".$_SERVER['HTTP_HOST'].$ext;
$admin_url  = $base_url . '/admin.php';

/* ExpressionEngine Configuration
-------------------------------------------------------------------*/
$config['app_version'] = "213";
$config['license_number'] = "0000-0000-0000-0000";
$config['debug'] = "1";
$config['install_lock'] = "";
$config['system_folder'] = "system";
$config['is_system_on'] = "y";
$config['allow_extensions'] = "y";
$config['site_url'] = $base_url;
$config['server_path'] = FCPATH;
$config['cp_url'] = $admin_url;
$config['theme_folder_url'] = $config['site_url']."/themes/";
$config['theme_folder_path'] = $config['server_path']."/themes/";
$config['save_tmpl_files'] = "y";
$config['tmpl_file_basepath'] = $config['server_path']."/templates/";
$config['avatar_url'] = $base_url."/uploads/system/avatars/";
$config['avatar_path'] = $config['server_path']."/uploads/system/avatars/";
$config['photo_url'] = $base_url."/uploads/system/member_photos/";
$config['photo_path'] = $config['server_path']."/uploads/system/member_photos/";
$config['sig_img_url'] = $base_url."/uploads/system/signature_attachments/";
$config['sig_img_path'] = $config['server_path']."/uploads/system/signature_attachments/";
$config['prv_msg_upload_path'] = $config['server_path']."/uploads/system/pm_attachments/";

/* CodeIgniter Configuration
-------------------------------------------------------------------*/
$config['base_url'] = $config['site_url'];
$config['uri_protocol'] = 'AUTO';
$config['language'] = 'english';
$config['charset'] = 'UTF-8';
$config['subclass_prefix'] = 'EE_';
$config['permitted_uri_chars'] = 'a-z 0-9~%.:_\\-';
$config['enable_query_strings'] = FALSE;
$config['directory_trigger'] = 'D';
$config['controller_trigger'] = 'C';
$config['function_trigger'] = 'M';
$config['log_threshold'] = 0;
$config['log_path'] = '';
$config['log_date_format'] = 'Y-m-d H:i:s';
$config['time_reference'] = 'local';

/* End of file config.php */
/* Location: ./system/expressionengine/config/config.php */

This is already nice and tidy. But it'd be great to consolidate our database information in here too, wouldn't it? That way, we can change all our system configuration in one file. This is how we do it:

/* Universal database connection settings
-------------------------------------------------------------------*/
$active_group = $ext;
$active_record = TRUE;

$db['.local']['hostname'] = 'localhost';
$db['.local']['username'] = 'root';
$db['.local']['password'] = 'root';
$db['.local']['database'] = 'some_database';
$db['.local']['dbprefix'] = "exp_";
$db['.com']['hostname'] = 'localhost';
$db['.com']['username'] = 'user';
$db['.com']['password'] = 'password';
$db['.com']['database'] = 'database';
$db['.com']['dbprefix'] = "exp_";

$db[$active_group]['dbdriver'] = "mysql";
$db[$active_group]['pconnect'] = FALSE;
$db[$active_group]['swap_pre'] = "exp_";
$db[$active_group]['db_debug'] = FALSE;
$db[$active_group]['cache_on'] = FALSE;
$db[$active_group]['autoinit'] = FALSE;
$db[$active_group]['char_set'] = "utf8";
$db[$active_group]['dbcollat'] = "utf8_general_ci";
$db[$active_group]['cachedir'] = $config['server_path'].$config['system_folder']."/expressionengine/cache/db_cache/";

By extracting out the majority of the variables (the ones that probably won't change depending on environment), and then using the $ext variable to switch the $active_group, we can adjust the database connection settings automatically depending on environment. There's one more thing we need to do. Open up your config/database.php file, empty it, and give it a solitary line:

<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');

require 'config.php';

/* End of file database.php */
/* Location: ./system/expressionengine/config/database.php */

Now, all references to the database configuration will be brought through the DB config file from the config.php file.

Alongside the standard configuration - paths, debug settings, URLs etc - we can customise a lot of ExpressionEngine's behaviour through a little-known technique called hidden configuration variables. A quick TextMate project search for 'Hidden Configuration Variable' bears 33 different variables with which to customise behaviour. Let's look at a couple of them:

$config['allow_textarea_tabs'] = 'y';

If you wish to preserve tabs in textareas, or let the user add a tab character, rather than shift focus to the next input, you can set this config item and all textareas in MarkItUp mode will preserve their tabs. Turning it off is as simple as setting it to 'n'.

Is the automatic JavaScript login reminder in the CP annoying you? Turn it off:

$config['login_reminder'] = 'n';

Do you want your formatted text links to automatically open in a new window?

$config['popup_link'] = 'y';

I'm sure you get the idea. There's a comprehensive list of the hidden configuration variables in the user guide.

I hope that this series has taught you one or two things about customising and using your config.php file to best effect. It's a fantastically powerful weapon to have in your arsenal, and it should make creating dynamic websites with ExpressionEngine much simpler.