• Ryan Singer over at 37signals writes about how to manage long breaks in personal projects. I’m currently using Basecamp to manage this project (which is largely the same method as Ryan describes with Backpack), but I need to settle on a GTD management system that suits the way I work.
• And via Ajaxian comes news of a Flash/GWT charting engine that looks like a prime candidate for generating the interactive charts that will be needed for Add It Up’s reporting system.

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.

Cart45 is a simple and easy-to-install ecommerce application developed by Phil Thompson with Soapy Co and Richard Morton. They’ve launched with a demo site quite literally selling itself, and some screencasts (sans sound, but that might just be me that is experiencing that).

And Olive is a “web app for web designers” by Sarah Parmenter for handling client requests, communication, and payment. Another one to keep an eye on (although in my experience some clients simply cannot be convinced to use anything other than the telephone and the occasional email to communicate).

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 a complete novice at WordPress it probably took longer than it should to get it all set up properly, but I’m impressed at how simple applying themes and plugins is on WP.

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.

When it comes to managing a project on which you’re the sole writer, designer, developer, and tester - is a commercial project management solution really necessary?

The answer, of course, is ‘yes’. Without a consistent workflow for identifying, prioritising, and managing all your tasks across multiple areas, it would be far too easy to get overwhelmed by the enormous nature of the task. By breaking the project down into ever smaller tasks (yes, this is GTD I’m talking about) progress seems attainable.

Basecamp is a perfect fit for the way I work, making it easy to make notes, jot down ideas, and quickly add new tasks as they occur to me. Even with just the first few items recorded I’m feeling more focused and have a clearer idea what to do first.

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!

I had a preview/beta copy of Silverback sent to me, but unfortunately I didn’t find an opportunity to use it (aside from filming myself browsing the web for a few seconds) before the beta version expired. I’ll definitely be pushing to use it at work if we ever get permission to carry out any more usability tests, though.

Garrett looks to have been using it to test the Sifter website; I haven’t really thought that far ahead, but it will certainly be an option for AddItUp.

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.