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.

As the final application will be for multiple users, there will necessarily be a significant amount of user account creation, maintenance, and security involved - but the core of the app is going to be the accounts, transactions, and reporting functionality. Should I develop from the outside in, and build the authorisation system first? Or build it from the inside out, and get the ‘fun’ stuff working initially - the transaction interpreter and categorisation engine - and then wrap the authorisation bits around that?

Both options are attractive. It would be great to get stuck straight into the meat of the application - after all, I’m the only one who will be using it for the forseeable future - but then one has to consider that locking down database access to an authorised user is likely to affect every database model I write.

On the other hand, starting with the registration and authorisation sections could take quite some time - I don’t want to kill my enthusiasm for the project that early on!

I think I’m probably going to start with the interesting bits first, on the assumption that the user auth stuff can be abstracted to a simple call in the constructor of every controller (and won’t require major re-writing of the database models later on).

If anyone has any experience that says otherwise, of course, please let me know!

If you were going to build a PHP application for use by others, would you even bother making it PHP4 compatible any more?

Responses were - with one exception - unanimous, with most people citing hosting as a key reason. Rachel Andrew, edgeofmyseat:

PHP5 all the way … more apps that require PHP5 means more people asking for PHP5 on shared hosting.

Jon Gibbins agreed:

Not worth the effort now I think. I suspect many hosting services to be upgrading now that PHP 4 is end of life.

And Simon Jones, studio24:

Encourage people to look forward not back.

CodeIgniter and PHP5

While there are a fair few PHP frameworks that only run on PHP5, CodeIgniter is not one of them - in fact, the only minor benefit one can obtain from using PHP5 is that it allows you to chain methods together when using its Active Record class:

$result = $this->db->select('id, name')->from('mytable')->where('name', 'Bob')->get();

So no real benefit to be gained in that respect. What PHP5 does offer, though, is many new functions, a completely new object model, and various other cool things.

At the moment I’m leaning heavily in favour of going with PHP5 - as someone else noted, it’s going to be much easier to port code from PHP5 to PHP6, than from 4 to 6 - but I’m still open to persuasion if anyone thinks differently.