I’m excited to announce that modules will be supported in time for the public preview on Friday! This is just one of the many steps taken to make Fever as flexible as possible.

Modules Overview

Modules are kind of mini-applications within a larger web application. They maximize component reuse by developing the controllers, models, libraries and views based solely on that module. When that module is needed, you simply add the path to that module in your configuration and you’re done!

An example would be a CMS that has the following components: blog, forms-builder and page generator. All three of those are components that make up the CMS (being the “larger” web application). The modules can be developed so that the views only contain the necessary HTML to present that functionality. The CMS can then use a layout (also included in Fever) to surround the view contents of the module. The layout will contain the primary HTML (usually CSS, JS, navigation, etc), and the blog module will supply the supplemental HTML to fill the rest.

How do you maximize component reuse? If you develop the HTML completely CSS-based (no inline CSS, please ;p), each application using that component can customize their own CSS file, include it in the layout and the component will look unique to each application using it.

Telling Fever You’re Using Modules

You can tell Fever that you’re using modules in your application two ways: configuration or through the FrontController API.

fever.app.useModules = true

or

<?php
$front = Fever\Controller\FrontController::getInstance();
$front->setUseModules(true);

At this point, your entire application must use modules. You will no longer be able to use simple controller-based functionality. That said, Fever implements modules a little different, and there’s some important information you need to know when using them:

What Makes Modules Different in Fever?

There may be cases where you need to customize a module’s functionality, or the module may require key information specific to each application. We recognized this, and added shared models and libraries. This means every module has access to each application’s models and libraries, and vice-versa.

Each module also has it’s own bootstrap to customize its MVC needs. While this is handy, module-based bootstraps do not have the same flexibility as application bootstraps. This is due to the way the request is handled.

An application’s bootstrap is called before the request/response objects are initialized and the FrontController actually does any work. This makes a difference in the module bootstraps as the request object has been initialized and the module has been identified. Beyond this, nothing is different.