On modules

by Naneau

Modules are a way of separating your software into re-usable blocks. For those new to the Zend Framework, it is often a source of confusion. I’m going to try to explain the philosophy behind them briefly, and give you a few tips on how to implement them.

The example given in the documentation is that of a site that consists of both a forum and a blog section. While they are both part of a single application, a blog is different from a forum and therefore separated. You may also find yourself in the situation that you want to create a new application later, which exists of a blog and a shop. If you have a blog module ready to go it will save you half of the development.

Deciding which parts of your application are not strongly linked, and could therefore be put in a module is really your own choice. You may find that you don’t have a need for modules at all. That’s fine, but just make to double check that, because nothing is more frustrating than having to rewrite code.

When writing modules, you should always try to keep in mind that if you play your cards right, you may be able to reuse them later on. That’s why all module-related code should be put in a single directory:

1
2
3
4
5
6
7
8
9
10
11
12
ModuleName/
    controllers/
        IndexController.php
        [...]
    models/
    views/
        scripts/
            index/
                index.phtml
                [...]
        helpers/
        filters/

You should be able to grab that directory later on, and put it into a different application. As you can see the ‘views’ directory has three subdirectories. There’s the ’scripts’ directory, in which you should put your actual views. The “helpers” and “filters” directories are, like you may expect, for view helpers and filters respectively.

As for the controllers, it is indicated in the manual that you can subclass Zend_Controller_Action and have all your actual controllers extend from that subclass. While this is of course a good way of avoiding code repetition, you may find that it will stand in the way of module portability. While I can’t give you a definitive answer on what is better (it really depends on the situation), if you can avoid using a custom base class, and use Zend_Controller_Action directly, do so.

One thing you should remember is that the naming convention for modules follow the coding standard. This means that if you were create a file called IndexController.php, for an index controller, the name of the actual class should be ModuleName_IndexController. Always prepend the name of the module, with an underscore, to the name. This should help you to distinguish controllers from different modules.

Setting up a module is relatively easy. In your bootstrap file (index.php) you can add it’s controller path to the front controller like so:

1
2
$frontController->addControllerDirectory('application/blog/controllers', 'blog');
//add a module called 'blog'

But if you use the conventional layout for modules (the one described in this post), and put them all under a single subdirectory of your application directory, you can just add all modules with one line of code:

1
$frontController->addModuleDirectory('application/modules');

As one last thing, please remember that even if you don’t use modules, you are using modules. The front controller will always look for a ‘default’ module. You don’t have to explicitly specify it in your controllers and directory structure, though. You can change the default module the front controller uses like this:

1
$frontController->setDefaultModule('moduleName');

Update

Andries, who is a nice guy that hangs out a lot on #zftalk, knows a lot about the zend framework, being on the team. He has put together two sample files for you to download with a default/conventional or modular layout for any application. Have a look at his blog. Just add water!