(Matchbox is the successor of Modular Separation. However, Matchbox is backwards compatible with its predecessor so you can switch over without problems)
Matchbox is a set of extended libraries for CodeIgniter that lets you organize your application in modules. 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.
You can find downloads and a comprehensive documentation at matchbox.googlecode.com.
Please feel free ask questions and post feedback in this topic.
If you have ideas or suggestions, in order to avoid this thread becoming too messy, I encourage you to post them to the Matchbox Development Google Group (http://groups.google.com/group/matchbox-development). That way I can look on each suggestion separately.
Quick Documentation
(Comprehensive documentation avaiable at http://matchbox.googlecode.com)
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');
