My favorites | Sign in
Project Logo
       
Search
for
Updated Oct 12, 2009 by zdknudsen
Labels: Phase-Design, Phase-Implementation
Introduction  
Familiarizes you with the concept of modules, teaches you how to make them and teaches you how to use them.

The Blessing of Modularity

A module is a self-contained component of your application and can contain an arbitrary number of resources of any kind (controllers, libraries, views, etc.). Modularity have several purposes, the first being helping you neatly organize your application. As sites increases in size, resource folders tend to become bloated and confusing to navigate. Using modules you can break your application into smaller components that are easier to manage. Secondly, if you should ever need to reuse a component in another application you don't have to search for every resource required by the component since you have already stored them in one directory and so you only have to copy one folder. Lastly there are the ready-made downloadable modules that can be installed by simply dropping its folder in your application and firing up the module.

Have It Your Way Then

Before you get your hands dirty you have to decide where to store your modules. You will most likely want to store them in /application/modules (which is the standard setting), however this is configurable. In the configuration file there is an array, $config['directories'] with just one item, 'modules'. This array contains paths relative your application folder in which to look for modules. You can add as many paths as you like, however the more you add, the more searches will be made with each page view. Also note that the searches are performed in the order of the array.

When you are done configuring the module directories, do remember to create them.

Mastering the Directory Structure

Modules have a strict folder structure and it is important that you adhere to this when developing. Here is an example.

- modules (1)
  - example (2)
    - controllers (3)
        example.php
    - libraries (3)
        examplelib.php
    - views (3)
        example_view.php
  1. The modules folder - Is the parent of any modules you create. Can be any of the directories configured in the previous step.
  2. The name of your module - Contains all the resources for this particular module. The name is restricted to letters, numbers, and the characters ~%.:_-.
  3. Resource folders - Are the same folders you find in your application directory (helpers, models, etc.). You only need to create folders for the types of resource that you need.

Controllers? Controllers!

The controllers themselves work like they always have. However, the way you store and access them are slightly different. At its simplest this is how it works.

www.example.com/module/controller/method/parameter
  1. The first segment represents the module in which the controller can be found.
  2. The second segment represents the controller that should be invoked.
  3. The third segment represents the method that should be called.
  4. The fourth, and any additional segments, represents the variables that will be passed to the controller.

As you may have noticed the only difference from the standard style is the module segment in front. There are two exceptions, though.

  1. If the controller is located in a subfolder then the subfolder must be added as another segment between the module and controller segments.
  2. If the controller have the same name as the module, the controller segment can be omitted.
  3. If the controller is in a subfolder and have the same name as the subfolder, the controller segment can be omitted.

Them There Resources

The process of loading resources will do all the thinking for you. When you try to load something, the resource will be looked for in the module in which the current controller reside and, failing that, in the resource folders in your application directory and then the system directory. If the controller is in the standard folder, then the module checking will simply be skipped. However, you might want to load resources from other modules (side-wide authentication resources for instance) and if that is the case you have two options.

  1. Every method of the Loader library (that loads resources) have been extended with an additional parameter, a module name. So you simply put the name of the module with the desired resource after the standard parameters.
  2. Due to the often unused last few parameters of the loading methods, you also have the option to use alternative methods that are exactly the same as the standard ones, except for the added prefix “module_” and that the module parameter is the first one (e.g. instead of $this->load->view('file_name', false, false, 'module') you would go with $this->load->module_view('module', 'file_name')).

If you wish to autoload a resource that is located in a module, you will have to tell the autoloader where to look. This is done by adding a key to the array items that are in modules. You can still autoload resource that are not in modules. Here is an example.

$autoload['libraries'] = array('database', 'session', 'module_name' => 'library_name');

A Little Assistance?

I know I said that loading resources required no thinking on your behalf. However, in a few cases you do have to give out a few instructions before you can load your resources without problems. Basically what happens is that when trying to figure out which module requested a particular resource, the file that called e.g. $this->load->view('filename') will be used to determine the module. However, in some cases you might need to exclude certain files in this search. Perhaps you are using a custom view library. In that case, whenever you call the custom method, the library will be considered the caller instead of your controller and so the module cannot be determined. Thus you will need to add the file to the configuration array, $config['callers'].

If you have multiple files with the same name, but you only wish to exclude one of them, you can also add a bit of the filepath to distinguish it from the others.

Still Here?

That pretty much covers the basics of modularity. However, if you wish to start developing modules for release to the public, I encourage you to read the Standards which covers good practice when developing open source modules.


Comment by boksiora, Oct 26, 2008

COOL,COOL,COOL, this Matchbox is really COOOOL!

little more detailed docs, please guys :)

Comment by huglester, Dec 10, 2008

yeah, documentation would be good one.

Comment by wnotowidagdo, Jan 28, 2009

Hi,

I create a file modules/my_module/libraries/MY_Controller.php, the MY_Controller.php content is

`class Admin_Controller? extends Controller { ...`

then I try to extend Admin_Controller? in modules/my_module/controllers/dashboard.php using

`class Dashboard extends Admin_Controller? { ...`

but somehow I got this error message

Fatal error: Class 'Admin_Controller' not found in

did I missing something?

Please help me.

Thank you.

Comment by zeratool.admin, Mar 11, 2009

the Admin_Controller? is not loaded by default, you have to include it.

require 'path/to/your/Admin_Controller?.php';


Sign in to add a comment
Hosted by Google Code