Django, CakePHP and CodeIgniter, part 4: the Model-View-Controller or Model-Template-View interactions

I’m back in the world of frameworks. So, I’m continuing the series, restarting from the very basics, and that would clearly be the model-view-controller pattern. This post is not a brilliant triple tutorial which explains in great synthesis everything you need to know about MVC in all three frameworks (Django, CakePHP and CodeIgniter) at once. Some day I will be able to write things such as that, but not today. Today I am just an apprentice, and here are some of my study notes.

So, CodeIgniter is very nice and flexible and makes it easy to grasp these concepts, since you can initially have only the controller, and then add a view, and in the end, maybe even a model. Very Lego-like. Django have their own methodology of not having a methodology. And they call that MTV, model view template. To them the model is the application itself, in a way. CakePHP relies very much on convention and file naming. To read more on the subject, click “Continue reading”.HELLO WORLD OF MVC

CodeIgniter is great for studying the Model-View-Controller structure of these frameworks. Because it applies it, of course. And also because with CodeIgniter you don’t even need a Model to start with. You can put together a simple “Hello World” Controller-View test case, and see what happens. If you want to go even more minimal, you can start with just the Controller.

So, what does the CodeIgniter Controller do? Exactly as its name suggests. The controller controls. It controls a good part of what happens between a web page being requested and the response being displayed. It doesn’t do everything, of course, the Web Server is still there, doing it’s job, handling the Requests and the Responses. The web application, in this case with the help of a framework, puts together the web pages that need to be sent with the Response. By the Server.

So, when you download the CodeIgniter 2 files onto your server and your server displays a nice encouraging Welcome message, it will tell you that the Controller that makes that happen is application/controllers/welcome.php and the view that is handling the presentation of what you are seeing is application/views/welcome_message.php. So, let’s take a look.

The controller just loads the view.

class Welcome extends CI_Controller {
       public function index()
                #echo 'welcome';

As you can see, for testing purposes, we could even skip the view and just echo some text. The simplest view is just a file containing a basic HTML page that can echo the PHP variables that the controllers passes it.

And the variables, that is the page content, usually comes from the model. Which usually gets it from the database. Using the Active record object-relational mapping, so you can interface yourself to the database through objects, instead of writing queries. In reality, the model could do much more then just the basic CRUD (database input and output). The model is the very logic of a web application, the business and otherwise logic, the brain. And I hope to someday see it in real action.

And what happens behind the scenes? Good question. I still haven’t explored the CodeIgniter source code much, certainly not enough. But even an apprentice like me can tell you that if you ask for the Web Servers calls upon the index.php script, by default (I’ve already written about mod_rewrite in another post). Just open the index.php with your favorite text editor, and peek inside. You’ll see that it does some environment setting up, and then calls the bootstrap script, at  BASEPATH plus ‘core/CodeIgniter’ plus EXT. If you echo or log that to see what is going on, you see that the bootstrap script can be found in your your CodeIgniter directory and more specifically in system/core/CodeIgniter.php. Why not read that too? Again we have some defining and requiring, and a lot of creating of instances of classes and such. So a fun thing to do is to look at the objects being created, printing them out with  var_dump or whatever. For example, with echo “<pre>”; var_dump($RTR); echo “</pre>”; you get a view of the routing class, which I think is the one which knows what controller to load and from where.

And of course, silly me, forgot to mention, this is because there is a file application/config/routes.php that defines what will happen when users asks for certain URLs, and out of the box it knows that it needs to welcome you, the very first user, with the welcome message. For the routes.php file contains this:

$route['default_controller'] = "welcome";
$route['404_override'] = '';

Is this at all clear? Some day I will put together proper tutorials explaining all of this very clearly and very schematically, right now I am just learning and all I’ve got to share are some notes I’m taking along the way.


Django is different. It’s not MVC at all, it’s MTV. Here’s an explanation: with Django, the view is about which information gets presented to the user, the template is about how it gets presented. “If we have a methodology, it’s that we are anti-methodology”, as Django’s Jacob Kaplan-Moss declares in this Google Tech Talk in 2006 (at about 13 mins). “A model is a blueprint for your data, it describes everything that there is about your data”, Jacob explains. Data is both data and metadata (stuff that “doesn’t fit into your database”). But let’s not get carried away. What happens to the Controller? It appears to be a bit all over the place in Django. Where does the “controller” fit in, then? Accordingly to the above quoted FAQ, “it’s probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.” And the view can call upon the model data directly, as we see in the tutorial. Clearly, Django it’s not as messy as it may sound. It is orderly in its own way.


What about CakePHP? It follows the Model-View-Controller pattern, as you can read here. How exactly? CakePHP likes “convention over configuration“, so models, views and controllers have to have certain names, and will automatically work together.

As we can see in the classical basic blog tutorial, after you have created a database, adjusted its configuration file and dealt with some mod_rewrite issues, the basic model is a php file that lives in app/models and has a name that describes what it does, like post.php which handles the posts in out blog. It would contain a class called Post. There would be a controller /app/controllers/posts_controller.php with a class called PostsController, which uses HTML helpers and calls a view, and grabs contents from a database with a simple $this->Post->find(‘all’). The view is the /app/views/posts/index.ctp template file, and is the usual mix of HTML and PHP variable printing.

This post is already too long, so I’ll end it here. There are other fun things to consider, such as helpers, behaviours, components, and will be done some other time. Have fun, and sorry that this post is not yet the tutorial that someday I will be able to write. But be patient with this particular apprentice, which is me, and I promise to improve daily. Wish you a nice day!

0) No More Static Web Sites (learning from mistakes #1)
1) part 1 : downloading – planting the framework tree
2) part 2: how does the server talk to the framework?
3) Django, CakePHP and Codeigniter, part 3: Models, data, relationships and foreign keys
4) Django, CakePHP and CodeIgniter, part 4: the Model-View-Controller or Model-Template-View interactions

5) Objects in frameworks – those who get the work done – CodeIgniter notes


About apprenticecoder

My blog is about me learning to program, and trying to narrate it in interesting ways. I love to learn and to learn through creativity. For example I like computers, but even more I like to see what computers can do for people. That's why I find web programming and scripting especially exciting. I was born in Split, Croatia, went to college in Bologna, Italy and now live in Milan. I like reading, especially non-fiction (lately). I'd like to read more poetry. I find architecture inspiring. Museums as well. Some more then others. Interfaces. Lifestyle magazines with interesting points of view. Semantic web. Strolls in nature. The sea.
This entry was posted in frameworks and tagged , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s