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

I’ve been working with CodeIgniter quite a bit lately, so I thought I’d record what I learn and share some of it too. Most of all I’ve been using a lot of objects. CodeIgniter 2 is very interesting in that sense. As you can see in the flow chart, one fundamental thing that happens early on is routing, which is when CodeIgniter decides which controller handles the request. A lot of object interaction happens – objects loading other objects into objects and objects calling other objects etc. Let’s study that puzzle a bit, since it’s useful.

The routing class matches url patterns to behaviours (controllers). The loading class loads other stuff into the controller, looping through the autoload configuration file and feeding new objects to an instance of the Controller. If something’s not in the autoload file you can use $this->load later to load it anyway. By Controller with a capital C I mean the CondeIgniter super object. It is the object that gets called using the $this costruct from controllers, models and views. In other cases, you ask for an instance. But I’ll get back to that.

CodeIgniter looks quite object oriented, so if you want to separate a certain functionality to reuse, you might want to create your custom libraries, which are basically classes. Helpers, I repeat, are just procedural functions instead.

The “other stuff” that the Controller has access too are: libraries, models, database objects, helpers, language and configuration files and packages. Other controllers are handled differently, in the CodeIgniter.php file.

CodeIgniter framework application flow chart

CodeIgniter framework application flow chart, from http://codeigniter.com/user_guide/overview/appflow.html

If you want to read about this in more detail, click “Continue reading”. Here is CodeIgniter’s application flowchart taken from http://codeigniter.com/user_guide/overview/appflow.html. BTW plugins have been removed. Remember, these are just study notes, not a definitive tutorial that may come some day. All corrections and suggestions and comments are welcome, thank you in advance.

As with the web applications of the old days, everything starts with a simple script file called index.php. But it doesn’t end there, not at all. After it does some essential configuration, like setting the location of the application folder, it calls the CodeIgniter.php file, as the comments put it “away we go”. And we do. Some things get required, hooks get handled, and most of all the chosen/requested controller gets instantiated (it extends the CI_Controller class). Inside the controller constructor we, as the comment puts it:
 // Assign all the class objects that were instantiated by the
 // bootstrap file (CodeIgniter.php) to local class variables
// so that CI can run as one big super object.

It loads the loader which then loads the other stuff.

THERE CAN BE ONLY ONE… THE CODEIGNITER SUPER OBJECT SINGLETON

Don’t worry about overpopulating your world with super objects, there can only be one, since it uses the Singleton pattern. Which means that a certain class can only have one instance, and if an instance exists then that is the one that is returned (the classical usage is for the db access object). You get an instance of the Controller, for example in custom libraries, like this (assign by reference!):

$CI =& get_instance();

Oh yeah, inside the Controller class, the get instance method does this:

public static function &get_instance(){ return self::$instance; }

And there is also a get_instance function inside the (procedural) CodeIgniter.php file:

function &get_instance()
{
return CI_Controller::get_instance();
}

I found this possible explanation here in this stackoverflow.com thread (comment by ircmaxell):

“Edit: Actually, now I understand. For PHP4 compatibility they had to do a double-global-variable-hack to get it to return the references properly. Otherwise the references would get all screwed up. And since PHP4 didn’t have support for static methods (well, properly anyway), using the function was the better way. So it still exists for legacy reasons…”

And the $instance variable is created in the constructor:

private static $instance;

/**
* Constructor
*/
public function __construct()  {
self::$instance =& $this;
…}

Read about this in the Creating libraries chapter of the user manual, and search about it on the stackoverflow.com Q&A site.

OTHER LIBRARIES

Some other libraries/classes you can use and explore cover functionalities such as: form validation, security, handling multilanguage sites, sessions and much more. Explore, work, play, read the source code, extend, and let me know how that works out for you. And, above all, remember, create your own classes!

WHAT’S THIS? WHAT IS IT?

Yep, that is a pop cultural reference. But let’s stay concentrated. What IS the PHP $this keyword? Why does it have all this power? As Doug puts in in one of the comments on the php.net website, “Inside a class definition, $this refers to the current object, while  self  refers to the current class.”  All controllers obviously inherit from the super object’s class, which is why they access it’s properties and methods with $this. You can use self when using properties and methods of a class statically, without instantiating it. Right? I do have to study Object Oriented programming much more, I know. Ever since I’ve heared Raymond Hettinger talk about subclassing in Python at the EuroPython 2011 conference, I feel there is so much more to this stuff. I will get to all of that, oh yes I will.

ETC.

I don’t have much time to study frameworks comparatively any more (another story, will be told some other time). I would like to take a peak at how do CakePHP and Django do this stuff, but I’m afraid today is not the day. Thank you for your interest and patience, hope this post has been at all useful, read you later.

OTHER FRAMEWORK POSTS:

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

Advertisements

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 CodeIgniter, frameworks, tutorials and tagged , , , , , , , . Bookmark the permalink.

2 Responses to Objects in frameworks – those who get the work done – CodeIgniter notes

  1. Andy Walpole says:

    I think it is an useful post. In order to get the maximum return on a PHP framework it is important not just to understand the underlying architectural pattern (in this case MVC) but also how they organise their own internal code. Then you can take away this knowledge and use it in your own projects.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s