Learning Kohana

In the previous posts in this series I discussed the first two major files which are loaded by Kohana. The first one is the index.php where every Kohana application starts, the second bootstrap.php which does the bootstrapping of Kohana. The bootstrap did two important things I’ll discuss today. It started the Kohana::setup method and it added several events.

The Kohana::setup method can be found in the Kohana.php file in system/core/Kohana.php

I’ll skip some of the lesser important things such as the definitions of constants or the setting of the timezone. The first important thing is the registering of Kohana::output_buffer as the output buffer for Kohana. I’ll take a look at this method in another post. Next is ’spl_auto_load_register’ which register Kohana::auto_load() as the auto_load method. This method will receives some attention.

What ’spl_auto_load_register’ does is simple, when an attempt is made to instantiate a object of a class that does not exist the registered auto_load method is called. This method will try to include the class so the execution of the script can continue. This removes the need to have includes before you instantiate an object and makes the overall code neater. You can register multiple methods with spl_auto_load_register, for example my Formation/Validation classes implement another auto_load method.

In Kohana the Kohana::auto_load method does the loading of libraries, controllers, models, drivers and helpers. It also handles the transparently extended classes. This in contrast with CodeIgniter where you’d have to use the $this->load syntax to first include the class and then instantiate it. Transparent extending works as follows:

Non-extended classes end with _Core. For example, Acl_Core stored in libraries/acl.php. However you can always call ‘new Acl;’ and it’ll load. This is because if no file is found which extends the class, i.e. a libraries/MY_Acl.php file Kohana executes an eval statement: ‘eval(class Acl extends Acl_Core {}’ This way transparent extending is achieved.

The Kohana::setup method continues with registering error and exception handlers which should be pretty clear. It also sets a utf8 header here. If you want you can override this anywhere else in your application. Some other stuff is handled now too such as the locale and the logging. The important thing that starts here is the methods attached to events.

The first method registered to system.routing is Router::find_uri, which attempts to determine the current URI. Next registered event is Router::setup which will conduct the routing and set the file, controller and arguments of the to-be-called controller.

Next event with a method is system.execute with Kohana::instance(), this is where Kohana continues and where the dispatching happens. It will be covered in the next post in this series. Next registered method is Kohana::show_404 attached to the system.404 event. You can run this event on your own when a user accesses a page he’s not supposed to but it is called at several other places in Kohana when something goes wrong.

Last method register to an event is Kohana::shutdown with the system.shutdown event. It’s the last thing Kohana does before shutting down. You can see the order of all the events in the bootstrap file although some are also called in Kohana::instance

A major part of the Kohana::setup is the loading of the hooks. This method is executed just before the first event (system.ready to which Kohana does not attach any method) is executed. This means that your hooks can attach methods to events at the earliest stage possible. See the documentation for more information.

So, that’s it for Kohana::setup(), in the next post I’ll cover Kohana::shutdown, render, output_buffer and the most important Kohana::instance() where everything revolves around.