Modules

Koldy framework offers easy way of embedding modules. Modules are separated group of controllers, models, views, scripts and libs that can be easily replaced or installed. You can create them in application/modules folder. Every module has its files inside of its own folder.

Every routing class must know how to handle URIs for modules and it has to initialize the right module if module case is detected.

So, the module structure looks almost the same as for the main project:

the_project_root
| - application
|	| - modules
|	|	| - module1 <- this is module name
|	|	|	| - controllers
|	|	|	| - models
|	|	|	| - library
|	|	|	| - views
|	|	|	| - scripts
|	|	| - module2
|	|	|	| - controllers
|	|	|	| - models
|	|	|	| - library
|	|	|	| - views
|	|	|	| - scripts

When routing class detects the module, it will then adjust the include path giving the module paths greater priority then classes that are not under the module.

For easier explanation, lets imagine we're making news module and we're using default routing class. The directory structure would be:

root/application/modules
| - news
|	| - controllers
|	| - models
|	| - library
|	| - views
|	| - scripts

Controllers

You'll probably want to handle requests on /news inside of your module, so you need to define IndexController in news/controllers/IndexController.php. Also define indexAction method.

What if you want to handle some news archive pages on URIs like /news/archive or /news/archive/page/2? There are two ways of catching this URL.

First way: create ArchiveController and define __call() method that will catch everything beneath /news/archive/*.

Second way: in IndexController define archiveAction() method and catch all other parameters there.

If you define both of the ways, then system will take the first way because it has greater priority. It will look up for archiveAction() in IndexController only if ArchiveController doesn't exists at all.

Libs and models

You can define any kind of library or model class within your module, but consider priorities. Module always has greater priority then application folder itself.

Example: if you define User model in news/models/User.php and the same class is defined in application/models/User.php, you'll get the model from news module only if you're working inside of model's scope. If you're trying to work with User class outside of news module, then you'll get the model from application/models/User.php. Please be careful about that. Or better, think of naming.

Views

Using views in application/views is easy and it will work as it is documented here. Difference between the views from application and module folder is just in passing the module name before view path.

Example: if you have view in news/views/base.phtml, then you should return the View class from controller's method like this:


class IndexController {

    public function 
testAction() {
        return 
View::create('news:base');
    }

}

It doesn't matter if you're in the module's scope or not, you must always write the module name before. The same rules apply to render() method.

Example: if you have file news/views/menu/submenu.phtml and you want to render that file inside of news/views/base.phtml, then call this:


$this->render('news:menu/submenu');

Scripts for CLI environment

The same naming rules as for views apply here. Check the CLI docs for more info.

CLIDB: Configuration