Like I would imagine many programmers, I have a tendency to get a little anal about naming my Controllers and Models. Combine this with the default behaviour of CodeIgniter to parse the URL segments into controller/function/id parts, and it all begins to get very messy unless some careful thought is put into this stage of a project.

For my finance application there are a few obvious ‘pages’ needed. A user will want to view their list of accounts, or an individual account. Using the default structure, a sensible URL design might be:

• /accounts to list all accounts
• /account/details/12345678 to view the transactions of a particular account

The latter URL would require a Controller named ‘Account’ containing a method named ‘Details’. That all sounds okay so far, but what happens when you throw Models and ORM into the mix?

I plan to use a hand-rolled ORM solution to handle the database interaction within the app, which would mean for the ‘accounts’ table, my Model class would be named… ‘Account’. And you can’t instantiate two separate classes with the same name. Problem.

Assuming (and sticking with convention over configuration) that the Models have to be named correctly (’Account’ for the accounts, ‘User’ for the users, and so on), how should I decide on the naming of my Controllers?

As I see it, there are two options:

1. Pick a convention for Controllers and stick to it. For example: account_controller, user_controller - I can even use the URL routing feature to redirect my original choice for URLs to the newly named controllers, although in my experience relying on routing can start to get messy.
2. Come up with a new design for my URLs and reflect that in my Controller names. This could be anything - /show/me/12345678, /list/transactions/from/12345678 - the possibilities are endless. This option has the benefit of avoiding complicated routing rules, but could prove less intutive to write and maintain.

I’m leaning toward Option 2, based on a combination of disliking excessive routing and loving beautiful URL design. I’d love to hear what conclusions other MVC application developers have come to, though.

At that time, I was planning to develop an e-commerce application (this was before the launch of Magento), so my reasoning was that a distributed web app should make it easy for programmers to work on backend code while allowing designers to hack on the templates without having to understand a bunch of complicated PHP statements.

CodeIgniter’s Template Parser Class

To pass data from the Controller to the View in CodeIgniter, you would normally load the view template and pass in an array of data:

$this->load->view('my_template', array(

    'page_name' => 'About Us',

    'page_content' => 'Hey, we are a great company!'

));

The array of data is transformed into local variables for use within the template:

<h1><?= $page_name ?></h1>

<p><?= $page_content ?></p>

That’s all very well with basic variables, but when it comes to arrays your template can quickly become cluttered with nested if, else, and foreach statements - and that can be confusing for non-technical designers or purely front-end (HTML/CSS) developers.

The Template Parser Class replaces those PHP echo statements with special variables that, in theory, are easier to understand:

<h1>{page_title}</h1>

<p>{page_content}</p>

<ul>

    {link_list}

        <li>{link_description}</li>

    {/link_list}

</ul>

For simple strings and basic arrays, the Parser class is easy to use - but once you start wanting to use different HTML depending on the values of your data, it can get messy. With embedded PHP in the templates, it is easy to throw a little logic into the View file - if it’s this then add that class name - but following a strict “No PHP” rule can have you jumping through hoops if your HTML isn’t architected to cope with displaying different types of data in the same way.

Of course, the whole point of MVC is that you shouldn’t be putting logic in your Views, so there really shouldn’t be any major hurdles in solely using the Parser class - but it’s going to take me a little while to get used to thinking that way.

For security reasons I decided to move the /system folder - which contains everything needed to run an application on CodeIgniter apart from the index.php file - outside of the web root. This is easily accomplished by changing the $system_folder path in the aforementioned index.php file… but then everything stopped working.

Five minutes of head-scratching later, I figured out what I had done.

Because I’m working on my local development machine, instead of moving the /system folder up a level, I actually moved the index.php down a level - and I’d forgotten to move the .htaccess file along with it, so Apache was dutifully trying to rewrite every request to a non-existent file.

Stupid mistake, easy fix.