An Introduction to CodeIgniter

The Write Stuff

There’s a well-worn urban legend that goes along these lines: faced with the dilemma that US astronauts could not get ball-point pens to work in zero-gravity, NASA spent a staggering amount of time and money developing a pen that would write perfectly in the conditions experienced during space flight.

The result was the Fisher Space Pen, a complex arrangement of pressurized ink cartridges and leak-free casing that could write upside-down, in extreme temperatures and in zero-gravity without so much as a blot.

Russian cosmonauts, meanwhile, used pencils.

Sadly it’s not true—pencils were used by US astronauts as well—but nonetheless it’s a wonderful little parable on the benefits of a simple approach.

As a web developer, you’ve probably found yourself in the middle of a PHP-based project where you can’t help but feel you’re heading inevitably towards a Fisher Space Pen of your own. You’re bogged in an ocean of code, not all of it bug-free, some of it superfluous, much of it commented out—and large parts of it interwoven with a complexity that would give an orb-weaving spider a migraine. What you’re looking for a is a really good pencil.

Say hello to CodeIgniter.

CodeIgniter is not a PHP substitute. When you dive into the world of CodeIgniter, you’re not leaving PHP behind—and why would you want to? PHP5 is a doozy of a scripting language for building state-of-the-art, dynamic web-based applications; its rapport with HTML is top-notch; plus it’s a great language for honing your OOP skills. It’s tight, secure and intuitive. For many of us, it’s the only server-side language for our needs.

CodeIgniter is a PHP-driven framework, containing a grab-bag of libraries, helpers, plug-ins and other resources, that takes care of many of the more complex procedures and functions for which PHP is famous. CodeIgniter does all the heavy lifting for you while maintaining high performance. It will simplify PHP syntax, streamline the code underlying your web pages, and—best of all—have you churning out dynamic, interactive, professional websites in no time.

Here are some of the principal benefits of coding your next project in CodeIgniter:

  • It makes coding in PHP simple, quick and user-friendly.
  • It’s an excellent framework for learning more about how PHP works as you code.
  • It underpins the Model/View/Controller (MVC) approach to web development—a best practice philosophy all developers should adhere to.
  • It’s built on a linear, easy-to-use folder structure.
  • It’s open source and simple to configure and customize for your own needs.
  • You can construct your own cleaner URI lines in CodeIgniter.

There are more reasons why you should start investigating this framework, and you’ll doubtless discover these for yourself when you visit and download the latest version (at the time of writing, version 2.0.1). Before you unzip and install the file though, head to the User Guide and read a little about CodeIgniter.

This is where you’ll see one of this framework’s best aspects—it has one of the most comprehensive and user-friendly how-to guides of any web development tool. If you can’t find what you need in the table of contents at (click on the tab at top right), head to the forums and join the ever-growing, highly passionate CodeIgniter community.

PHP Made Friendly

Once you start experimenting with CodeIgniter, you’ll find yourself quickly warming to its methodology. Of course, this assumes you’re familiar with PHP. You’ll need to have a good working knowledge of how PHP interacts with a database and its relationship with HTML, not to mention an understanding of basic PHP syntax, before you start working with CodeIgniter.

Functionality that might have taken you large chunks of PHP to get happening can be whittled down to, in some cases, one line of code with CodeIgniter. This might apply to anything from outputting text in a browser to form field validation, adding a Captcha facility or setting up cookies.

To illustrate how simple it is to use CodeIgniter for a project, we’re going to build a very basic website that outputs hard-coded content to a browser. This is ground-level developer stuff—but the aim is to show just how quickly and effectively CodeIgniter can work, as well as provide you with a background to the framework itself.

Once you’ve nailed the basics, you’ll move quickly into using CodeIgniter to build blogs, content management systems, forums, or any highly interactive, hands-on web application you can think of.

Before we get started, however, it’s worth taking a split-second course in MVC architecture—the programming structure CodeIgniter is built around.

Tiers Come Easy

The Model/View/Controller approach to programming aims to keep the business logic of an application separate from the display logic, splitting the presentation aspect of an application (what the user sees in their browser) and the nuts and bolts that drive that application into three interconnected tiers:

  • The Model, which represents data structures. Classes contained within the Model tier will contain methods that interact with a database.
  • The View, which looks after presentation. A View will normally be a web page, but can also be a page fragment like a header or footer.
  • The Controller, which does most of the hard work, and is an intermediary between the Model, the View, and any other resources needed to run your application.

Separating a project in this manner means each tier does its job extremely efficiently, maintaining its relationship with other tiers yet operating within clearly defined boundaries. It also means multiple Views and Controllers can interface with the same Model, and new or different Views and Controllers can interface with a Model without forcing a change in the Model design.

You’ll find plenty of information out there on the web to help you grasp what MVC is about and why it’s worth building your applications around the MVC axiom. Once you start familiarizing yourself with CodeIgniter, MVC will become far less abstract.

It’s a Set Up

Step one is to download and install CodeIgniter. You might want to squirrel this original copy away in a templates folder. Each time you start a new project, you can copy the necessary folders from this template, customizing them as you go along. For example, you’re not going to need to copy the user guide folder or license file every time you start a new project.

What you will need is the index.php file, and the two main folders: system and application. It’s the application folder you’ll be working out of most of the time, but it’s worth taking a peek through the subfolders in the system folder.

It’s in here that the mechanics behind CodeIgniter’s functionality are contained—the libraries, helpers, plug-ins and classes that you’ll be drawing on as you build your application.

Don’t be afraid to study the code —everything is explicitly commented, with explanations laid out neatly and in that dialect so alien to many programmers: plain English.

Clean Up Your URIs

One of the advantages of CodeIgniter is the ability to orientate yourself via the URI line. It’s in here you’ll be typing the names of your controllers, which in turn will launch corresponding view files responsible for output in the browser.

By default, index.php will be included in your URI, such as:

ci.com/index.php/page/my_output

where page.php is the name of your controller, with a class containing a method called my_output().

You can easily remove the index.php chunk, and streamline that URI line, by using an .htaccess file with your own custom-built regulations. On this page, you’ll see a dead easy example to include in your project which will tidy up your URI line and allow you to simply access controllers without the need for any mucky index.php nonsense. You can find an in-depth tutorial about .htaccess files here.

We’re Home

Once you have your project blueprint set up, and you’ve included a handy .htaccess file to smarten up that URI line, type the project folder’s location into your browser and see what happens. For the purpose of this tutorial I’m using Xampp as a local testing server. My CodeIgniter project, which I’ve called ci_tute, is in my htdocs folder, so if I type localhost/ci_tute into Firefox’s URI line I get CodeIgniter’s custom welcome screen.

welcome screen

The HTML for this screen is contained in the views subfolder (within the application folder—the main folder you’ll be working out of), in a file called welcome_message.php. This makes perfect MVC sense—what we see in the browser comes from our View tier of programming logic. But the real graft behind the browser presentation is taken care of by a controller (in the controllers subfolder, natch) called welcome.php.

Open this controller up.

welcome.php

Inside, you’ll see a class with two simple methods:—your garden-variety constructor, and an index method. The index method is the crucial one here. It will get called by default when the welcome controller is called upon—and this occurs when you type the controller name in the URI line.

So why didn’t we need to type localhost/ci_tute/welcome into the URI line? Because the welcome controller is set as the default. You can change this with a few keystrokes but you must understand that a controller is accessed in the URI field of your browser, and that the controller’s index() function is responsible for the default output.

Type localhost/ci_tute/welcome—you should see the same welcome screen. In a CodeIgniter project, you’ll be creating all kinds of controllers linked to their own specific view files, which when typed into the URI line will call up the presentations those views are responsible for.

It’s important you know where among the folder hierarchy this default controller is set. Open up your config subfolder (as always, in application) and take a look at routes.php.

config folder

This config folder is where you’ll head to customize the structure of your project, whether it’s creating automatic settings for loading libraries or inputting the access values of the database you’re using. The routes.php file is as simple as they come. You’ll see an array named $routes with a key of  default controller, the value of which is welcome. You can change this value from welcome to any controller you create.

Establishing Control

In your application folder, the three subfolders you’ll be getting to know best are your controllers, models and views—there’s that MVC beast we talked about earlier. When you create your application according to the MVC architecture, you’ll be saving the various files associated with each of the three tiers within its corresponding folder.

The other folder you’ll rapidly become friends with is the config folder—and for anyone out there who’s had a configuration-related nightmare, rest easy: CodeIgniter makes configuring your project to whatever specifications you require a doddle. Changing your home page URI, your site’s character set or even the date format you’d like to use is often just a case of typing a single word into a preconfigured array.

Let’s create a controller—the file that will be talking to the view (which will output content to the browser). In your controllers folder, create a new file and simply call it site.php.

Within your controllers you’ll be creating classes, just as you would with everyday object-oriented PHP. And the vital thing you need to know about controllers is the class they contain must have the same name as the controller’s filename. In our case the controller file is site.php, so our class will therefore be called Site (capitalized, following the general naming convention of classes in PHP).

The second thing you should know about your controller is that you’ll need to extend its class to its parent class, which is CI_Controller. This parent class, contained within the core subfolder in your system folder, is a kind of  “super class” that all the useful libraries you’ll be calling on in CodeIgniter will be assigned to.

If you become confused, head to the system folder, open up the core subfolder and check out the file Controller.php. You’ll see the CI_Controller super class in there, and the commenting will help walk you through it.

controller.php

Once you’ve created your Site class, stick an index() function inside it. Remember, this is the method that will automatically be instantiated when you call on your site controller.

Your controller class syntax should look like this:

<?php
class Site extends CI_Controller {
    function index()
    {
    }
}

You can always refer to your already-written welcome controller and use that code as a guide.

Our next move is to set up a view file, containing some content, for our site controller to talk to. But first, let’s test to see if our controller is working nicely by echoing something out onto the screen.

You would never normally do this: presentation directly from a controller is utter heresy in the church of MVC. Still, it’s a good idea to put an echo command into your index() method, see that it works, then comment it out and keep it there as a handy debugging tool. You can always delete it once your project is complete.

<?php
class Site extends CI_Controller {
    function index()
    {
        echo 'Ground controller to Major Tom';
    }
}

Type the site controller into your URI line (in my case, localhost/ci_tute/site). There’s your controller, brazenly bypassing MVC standards by outputting our echo statement, but happy to show you it’s ready to roll.

You could go ahead and write a similar method straight after index(); call it echo_stuff() if you like, and echo out some more content:

    function echo_stuff()
    {
      echo 'Have some more content';
    }

Now if I type localhost/ci_tute/site/echo_stuff into the browser, I see the new content. The hierarchy of controller classes and methods is easily discerned from the URI line.

Moving Home

At the risk of getting slightly sidetracked, now might be a good time to open up routes.php again and change your default controller. How do you do it? Scrap welcome as the value in $routes['default controller'] and insert site. Done. Now you don’t have to type site into your URI line; it’s your default home screen and whatever is in your index() method in the Site class will automatically launch.

Enjoy the View

Let’s create our view file and hook it up to our controller. Remember, our view will contain presentation output, and in this case it’s going to be plain old HTML, so create a new file in the views folder and call it site_view.php.

This naming convention—adding _view after the controller name—is not written in stone. Plenty of web developers simply call their view files the same as their controllers—for example, site.php. There’s no clash of names as they’re contained in separate folders. I like to know at a glance what’s a view, what’s a controller, and what’s a model—which is why, if I was to create a model for our site.php file, I’d name it site_model.php. You can choose whatever convention suits you best.

Here’s what my site_view.php file looks like inside:

<!DOCTYPE HTML>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset="UTF-8">
<title>The Web's Most Basic Site</title>
</head>
<body>
    <section id="container">
        <h1>Not a bad view, huh?</h1>
    </section>
</body>
</html>

Now we can launch this stunning webpage from our controller. And here’s where the simplicity of CodeIgniter syntax really will make you a happy coder.

Firstly, comment out that echo statement from before and keep it there as a debugging tool for later. Add this line of code into your index() method:

function index()
    {
      // echo 'Ground controller to Major Tom';

    $this->load->view('site_view.php');

    }

Highly readable and concise, isn’t it? Go to your index page now in your browser (localhost/ci_tute/site)—you’ll see the new content generated by site_view.php.

test page

All we’re doing is telling CodeIgniter to load the value of our view file, and with some pretty straight-up syntax. While what we’ve achieved is hardly complex, this is only touching to the tip of the CodeIgniter iceberg. Try creating an array of values to experiment a little further, say:

function index()
    {
      // echo 'Ground controller to Major Tom';

      $arr['value1'] = “First subhead”;
      $arr['value2'] = “Second subhead”;
      $arr['value3'] = “Third subhead”;

      $this->load->view('site_view.php', $arr);

    }

What we’ve done here is create our array of keys and values called $arr, then passed it into our load statement as a second parameter. Not much will happen at this point—we’ve merely informed our view file that it has a second parameter called $arr to do something with. But if you go to your site_view.php file and actually do something with the array, like:

<section id="container">
    <h1>Not a bad view, huh?</h1>
    <h2><?php echo $value1; ?></h2>
</section>

You’ll get a nice little subhead echoed out. You can do the same for the other two values in the array.

We’re only brushing the surface of CodeIgniter’s capabilities, and we haven’t even seen how it can operate with dynamic content. The real beauty of this framework could be illustrated much more clearly with a database, where we could extract content from a table with a simple query statement and pass it to our view. We’d do this with the aid of a model class—something we haven’t broached, but which is incredibly similar in nature to our controller. And our query statement might look something like this:

$this->db->get('tablename');

All we’re doing is accessing the database (db) table ('tablename') with a get function—one line which replaces all that wading about with messy SQL syntax. And we haven’t even started on using CodeIgniter to validate forms, or send emails, or buddy up with jQuery.

Hopefully this taster might whet your appetite. If, like me, your first experience with CodeIgniter made you sit up and realize this was the way you wanted all your web applications built, you’ll be pleased to know it will take little time to get started down that road.

You have all the tools you’ll need on the CodeIgniter site, not to mention some cheerful help from the forums, and there is a mountain of tutorials on the web that’ll help you become adept at it.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Stormrider

    I used CodeIgniter for a recent project, and didn’t like it. I found it far too limiting for what I was trying to do – it works for the majority of bog-standard websites that do the same things, but who does sites like that any more when there are so many out there? There is always something needed that is slightly outside being easy with CI. The support / framework behind models in CI is very lacklustre as well, nothing special there at all. You pretty much have to write that bit from scratch, and that’s surely where most of the heavy lifting takes place!

    CI does Controllers and Views OK (Although I prefer using a simple templating system for my views so I don’t even like CI’s views either), and has some interesting libraries that come with it, but that’s about all I found. I dread having to work on that project again…

    I have developed my own framework now which is much better to use (IMHO!)

    • Tom Museth

      Fair enough; there’s not much point using these sorts of frameworks or platforms if you don’t feel happy with the way they work, or if you have your own templating system. I know people who feel the same way about WordPress, for instance – that it might be good for bog-standard blogs, but that they all end up looking like they’re born from the same template and don’t offer much diversity.
      For me – and I’m still learning a lot about how CI works and how I can apply it – it offers a streamlined approach, one that doesn’t cut back on functionality or efficiency, but saves me tying myself up in acres of code I can’t dissect or that I don’t fully understand. The way it takes care of sticky data, form validation, database querying – it’s just so neat and smooth, and in a world where time is money, it kinda makes sense.

  • aditya menon

    I’ve been using CodeIgniter since a month now, and can confirm that it is absolutely wonderful! I’ve even learned OOP the Easy Way by learning CI. I was just starting a project which I was sure would end up as the space pen, but bumped into CI at the perfect time. I’ve fallen in love with this pencil ever since :)

  • SteveJ

    Very interesting introduction – thanks. I’m using Cake just now and CodeIgniter seems very similar. Which do you think is better? How would I chose between the two ?

    • Tom Museth

      Haven’t tried Cake, but will surely get into it. I’ve heard a lot about it, most of it pretty positive.
      But definitely give CI a go – you can start with a basic CMS or something similar. Explore the libraries, helpers and classes first, then see what you can apply. There are tutorials all over the web, but you can get plenty of tips from the CI forums.

  • Drazen Mokic

    Yap, CI is very good and one thing you forgot to mention is that CI has one of the best, if not the best documentation of all PHP Frameworks out there ;)

    • Tom Museth

      I’m sure I put that in ….

      • http://www.onsman.com Ricky Onsman

        “Before you unzip and install the file though, head to the User Guide and read a little about CodeIgniter.

        This is where you’ll see one of this framework’s best aspects—it has one of the most comprehensive and user-friendly how-to guides of any web development tool.”

      • Drazen Mokic

        Yep, you did. I am sorry!

  • Aaron

    I am sticking with plain old PHP5.

    • Tom Museth

      I hear you. It took me ages to write some of my class templates, and it’s hard to let them go now that this young upstart called CodeIgniter has brazenly swanned into my life. Tradition and all that …

    • Drazen Mokic

      Thats nice since CodeIgniter is just plain old PHP5, with some functionality from the beginning :)

  • Darren L

    Nice to see SitePoint become a little more diverse. I really enjoy CodeIgniter and hope SitePoint publishes more articles like this.

    @Stormrider you don’t fully undestand CodeIgniter. When you work with a team and need quick documentation as well as time to focus on the actual project and not your framework you will understand :).

    • Stormrider

      Nope, I completely understand. I work in a team all the time, and without a doubt the site we used CI for turned into one of the worst I’ve ever worked on, and the ones using my own framework have been faster and much easier. I used the CI docs extensively and my main disappointment with it all was in the model – there was barely a starting point, you are pretty much given a DB abstraction class then told to build the model’s functionality from there, which is the first thing I’d expect a framework to do, rather than spend time creating a ‘neat’ way to access other classes using ‘$this’ (even though you have this weird concept of having to ‘load’ objects first, and I’d argue this is far from being a neat way to access objects anyway).

      The methods I use now are much more intuitive anyway, and much more in keeping with the way php normally deals with objects that it doesn’t need much documentation anyway.

      Maybe other popular frameworks out there are better, but CI has put me off trying another one for a while!

  • Huzzi

    Checkout the newest php framework called FuelPHP.
    Fuel is a simple, flexible, community driven PHP 5.3 web framework based on the best ideas of other frameworks with a fresh start.
    http://fuelphp.com

    • Tom Museth

      Will do, thanks for the tip.

  • SteveY

    Excellent introduction, but the one thing you didn’t mention about CI is the future-proofing aspect. When the initial developer writes a web project in CI and then leaves the company, anybody familiar with CI could take over and carry on developing, whereasif it had been written in someone’s personal framework the next developer will have to spend hours, days and weeks finding out how it was written before they could get down to any productive work. Why re-invent the wheel and create something that no-one else can work with, when the job has been done so well already.

    • Tom Museth

      … unless they’re superbly good at commenting their code. But yeah, CI certainly makes life easier in that respect.

      • DaveBowman

        > unless they’re superbly good at commenting their code

        Which happens exactly how often? Riiight, never!

  • Carlos

    I have been working with CodeIgniter since the first version 1.6.x and now on the last version 2.x is a great upgrade to all my new projects to handle with this wonderfull framework.

    In response to Stormrider message, I think he likes the “already-done” framework approach of a CMS rather than a framework (like Drupal, WordPress, etc.) remember a framework is the metabase to create stunning applications like CMS or Websites like that, the main angular stone of any framework is the flexibility and CodeIgniter is light and great to do that (and if you like another template manager you can use Smarty inside CodeIgniter)…

    Just my two cents…

    • Stormrider

      No, not at all – I work in Drupal a lot and hate it. I use a framework, not a CMS.

  • kaf

    Thanks for writing this article. CI is a great framework and useful if you are trying to get into database driven websites and you don’t have much experience.
    I used CI for years at my previous job and I found the documentation was amazing, and the community very helpful.

    However I completely agree with Stormriders assessment. While it’s a great introduction to MVC and perfect for self taught beginners, most professionals will give it a miss. In fact like Stormrider, CI inspired me to write my own framework using some of the great ideas in CI.
    Unfortunately Models are where CI really falls over. And not just a little bit, but big time. It seems to be written for people who don’t really understand OOP as it uses the OO mechanisms but completely ignores OOP normal practices in such a way as you completely lose all the benefits.

    Some of the great benefits of Models CI just doesn’t deliver are: That you can send an array of Objects (lets say Products) out to your template and you can access all the fields as object properties and even call methods to get related media such as images. And you can use the magic __get() function to let you process some of those properties or even create new ones that aren’t necessarily in the table. In contrast CI expects you to throw arrays of arrays around everywhere as if we were still in the 90’s !!

    Another benefit is you can just edit your objects properties and simply call the save method. eg $product->price = $_POST['price']; $product->save();
    Because CI doesn’t really use OOP principles you just can’t do this.

    If you ask the CI forums why you can’t do these things they try to tell you that what you a talking about isn’t a Model but and ORM (Object Relational Mapper)…… err……….no. An ORM was a way to represent tables as objects back before MVC was common. The Model in MVC is SUPPOSED to be an ORM. Thats the whole point!
    Well I got really angry at this and decided to roll my own framework.

    However being an open source thing there are plenty of modules you can plug in to CI. One being an Object Relational Mapper. In fact I think there are a few. So if you want to do that then I think it could be a solution. Beware compatibility issues with other plugins though. I couldn’t get all the plugins I wanted to play nice.

    If you really want to try a good framework, Kohana looks good. It’s a fork of Code Igniter and has an ORM built in! It also seems to fix a LOT of CI’s other bug bears. However the community isn’t as big and the docs not quite as clear so there are some sacrifices.

    All this being said though, if you are a self taught scripter who is still using PHP is a scripting language (even though thats not what it is) as if we were back in PHP3 days (inline php and html) then I fully recommend Code Igniter. It’s infinitely better that what you’re doing now and it will give you a great foundation in MVC architectures and to some extent the OO mechanisms in PHP.

    All in all CI has it’s place and I’m glad it’s around. It’s still pretty cool and has some really great ideas.

    • Stormrider

      This is exactly right, and exactly what I think about the Models in CI, and exactly how models in my own framework work!

      $objProduct = new Product($intProductID);
      $objProduct->price = $decNewPrice;
      $objProduct->save();

      or even, because you can define relationships between entities,

      $objOrder = new Order($intOrderID);
      $objOrderlines = $objOrder->getOrderlines();

      foreach ($objOrderlines as $objOrderline) {
      print_r($objOrderline);
      }//foreach

      All of the functionality in the above code is built in to my framework – you don’t have to define the getOrderlines method (just put in the details about the relationship between the 2 into an xml file), or the save method, or anything else. This is how a model should work out the box IMO.

      • Darren L

        @Stormrider I see you require an ORM. The great thing about CodeIgniter is it does not include an ORM which makes it benchmark better than other frameworks. You can attach one like Doctrine however.

      • Stormrider

        There is a problem in this obsession with benchmarks and shaving microseconds off load time… the most important consideration is good, maintainable code, and then look at efficiency if there are any SIGNIFICANT bottlenecks.

        It’s not just the lack of ORM, it’s the fact that it tries to bundle everything to do with one type of content into one class, then having to use their weird ‘loading’ system in order to use it. Having to build arrays of data to pass to a view then offload it all to the view when you instantiate it is a bit weird as well.

        I also disagree with the statement in the article above that the controller should do the bulk of the work – I always thought it was best practice for the model to do all the heavy lifting, and leave the controller as light as possible, just to act as the mediator.

        I don’t require an ORM, I have my own already, the code above is from mine! Doctrine is a bit long-winded for me.

      • Darren L

        Ah yes Stormrider I see your point. I too agree most work should be done in the model. Autoloading is usually the replacement for how CodeIgniter does it.

  • Richard

    CI is great. Also take a look at the Kohana PHP. It originally evolved as a fork of CI, but is now in its third iteration and is quite a flexible PHP5 framework. It’s fast moving, but has become more stable as of version 3.

  • Haneez Haroon

    I started using the framework recently and its awesome.

    I really like the way how representation is handled with VIEWS and its really light.. Also cuts down loads of time we have to spend just to get a form validated, etc..

  • kira8080

    I’m surprised no one mentioned Kohana yet.

  • Robbiegod

    And my favorite CMS is built on CI, Expression Engine. If you’ve never used, try it out, take it for a walk. It makes making dynamic websites fun again.

  • Luke Morton

    Yeah I wish this was an introduction to Kohana :( It’s leaps and bounds ahead of CI, but not as widely known.

  • Andreas Lagerkvist

    What I don’t like about CodeIgniter (and many other frameworks) is that they treat one controller as one page type. I prefer to have one controller per module (not model).

    It’s extremely common that you want to re-use modules on more than one page (a recent comments block for example), and having all the code for one particular page in the same controller means you have to duplicate that code on the next page that should use the same module.

    Granted, the model should take care of most of the heavy work and the controller should preferably just do stuff like $recent_comments = CommentsModel->getRecent(5); but I find that many times you need to do a little bit more than that, especially if the page inserts data as well as outputs it.

    I prefer a slightly different approach where each page type is represented simply by a list of module-names. And each module has its own controller and view(s). That way I can easily pull in any module I like on any page I like without duplicating anything but the module name.

    My own framework works this way: http://a-framework.org/

    • Stormrider

      “$recent_comments = CommentsModel->getRecent(5);”

      Ugh, it’s that kind of code that makes me hate models in CI. The model should represent something, not be simply a collection of functionality related to the same entity. Also, individual items and collections of items should be totally separated, not bundled together in the same object!

      • Andreas Lagerkvist

        I actually just put that in as an example. Not sure how CI handles that sort of stuff tbh.

        My main concern with CI (and most frameworks) is, like I said, that they always treat one page as one controller. Even though one page almost always consist of a number of modules with different functionality (that should each have their own controller and view(s)).

        Structuring the code modularly allows the developer to much more easily move things around or re-use modules on several pages.

  • Paul

    Honestly while I see the benefits of frameworks, I would like to stress a point of negativity with them.

    I understand that many of you are seasoned programmers with a lot of experience and therefore your going to frameworks after proving that you can code monster apps with ease.

    My issue is with the notion of ‘programming is so easy with frameworks, even a dumbass can do it’

    I’ve encountered 2 ‘programmers’ in the last 3 years who raved about frameworks, they were given 6 projects over the course of 3 years in their respective organisation, none of which completed, they would both hit walls with their respective frameworks (right about the time skills/experience would be a good thing) and suddenly announce that they needed to reprogram the project in a NEW better! Bigger! framework.

    So, while I like experience programmers using frameworks, the danger is the appearance of fly by night cowboys…

    • Tom

      I wouldn’t say CI is for dumbasses. You still need to get to grips with its mechanics and terminology – which is fairly intuitive, but still takes some time to absorb.
      But planning is the key, and not just for a CI project, but any project, to avoid having to switch into reverse halfway into things and start again. I’ve been taught you should spend around 75% of the project timeframe in planning, maybe 15% coding and the rest in usability testing, shoring up security and general mopping up. Sounds weird, and it’s pretty hard to follow sometimes – like most people, I’m just generally itching to get typing code.

    • tomk

      I can understand your frustration. Having come from an engineering background, I know that any long term project will no doubt suffer from the ‘New Technology’ syndrome and that’s precisely where the term ‘Shoot the Engineer’ came from. As an engineer I can assure you that no design is ever ‘Done’. (in the engineer’s mind)
      Now just plug ‘Programmer’ into all the above scenario you have your situation.
      Having said that …. most ‘design’ firms hire project/program managers, who’s responsibility is to keep the engineers/programmers reined in. In cases where these entity’s are not in place or they have minimal understanding of the processes involved in development, the inmates are running the asylum and the project is doomed from the start.
      Not to totally defend the programmers, but I’ve been on both sides of the fence:

      inmate: (halfway through the project) “I want to refactor using this great new framework”

      manager: “NO!”

      Simple!

      thanks for listening,
      tomk

  • Anonymous

    “You can attach one like Doctrine however”

    I’d rather suggest to also take all the other Symfony2 components and check how they work compared to CI.

  • tomk

    Wow …. lot’s of opinions … so I thought I’d weigh in. I’ve used CI casually for about 2 years now and before that hand coded applications in PHP, but not enough activity to develop my own ‘style’. I was looking for some way of standardizing my coding practices and stumbled on CodeIgniter at about version 1.6. A framework seemed a good way to get my code organization act together and CI’s documentation helped me get through the initial learning curve. Since then I’ve looked at and sometimes tried other frameworks and have used my CI experience as a basis of comparison. I discovered that the basic concepts for most frameworks are very similar, so knowing CodeIgniter made it easier to understand the others.
    Getting into a peeing contest over what a ‘model’ should be in CMV paradigm is great for the seasoned coders, but if your new to CMV and Frameworks, I would recommend CodeIgniter wholeheartedly. The documentation is superior (by open source standards — IMHO), you’ll get up and running quickly and it will give you a basis for comparing other frameworks. IMHO — It’s worth the effort!
    Heh! — Thanks for listening,
    tomk