Category:Extensions | Category:Extensions -> HMVC | Category:Module
Modular Extensions - HMVC
Modular Extensions makes CodeIgniter modular. Modules are groups of independent CI components (typically, model, controller, view arranged in one application sub-directory) that can be dropped into CodeIgniter applications. HMVC stands for Hierarchical Model View Controller, which is a fancy way of saying nested modules!
Module Controllers can be used as normal Controllers or HMVC Controllers and they can be used to help you build view partials.
Modular Extensions installation
1) Start with a clean CI install.
2) Set $config[‘base_url’] correctly for your installation.
3) Access the URL domain/subdir/index.php/welcome => shows Welcome to CodeIgniter
4) Drop Modular Extensions libraries into application/libraries and application/helpers directories as specified.
5) Access the URL domain/subdir/index.php/welcome => shows Welcome to CodeIgniter
6) Create module directory structure application/modules/welcome/controllers.
7) Move controller application/controllers/welcome.php to application/modules/welcome/controllers/welcome.php.
8) Access the URL domain/subdir/index.php/welcome => shows Welcome to CodeIgniter
9) Create directory application/modules/welcome/views.
10) Move view application/views/welcome_message.php to application/modules/welcome/views/welcome_message.php
11) Access the URL domain/subdir/index.php/welcome => shows Welcome to CodeIgniter
You now have a running Modular Extensions installation.
Installation Guide Hints:
-Steps 1-3 tell you how to get a standard CI install working - if you have a clean/tested CI install, skip to step 4.
-Steps 4-5 show that normal CI still works after installing ME - it shouldn’t interfere with the normal CI setup.
-Steps 6-8 show ME working alongside CI - controller moved to the ME “welcome” module, the view file remains in the CI application/views directory - ME can find module resources in several places, including the application directory.
-Steps 9-11 show ME working with both controller and view in “welcome” module - there should be no files in the application/controllers or application/views directories.
FAQ
Q. What are modules, why should I use them?
A. http://en.wikipedia.org/wiki/Module
Q. What is Modular HMVC, why should I use it?
A. Modular HMVC = Multiple MVC triads
This is most useful when you need to load a view and its data within a view. Think about adding a shopping cart to a page. The shopping cart needs its own controller which may call a model to get cart data. Then the controller needs to load the data into a view. So instead of the main controller handling the page and the shopping cart, the shopping cart MVC can be loaded directly in the page. The main controller doesn’t need to know about it, and is totally isolated from it.
In CI we can’t call more than 1 controller per request. Therefore, to achieve HMVC, we have to simulate controllers. It can be done with libraries, or with this “Modular Extensions HMVC” contribution.
The differences between using a library and a “Modular HMVC” HMVC class is:
1) No need to get and use the CI instance within an HMVC class
2) HMVC classes are stored in a modules directory as opposed to the libraries directory.
Q. Is Modular Extensions HMVC the same as Matchbox?
A. Yes and No. Like Matchbox, ME makes modules “portable” to other installations. For example, if you make a nice self-contained model-controller-view set of files you can bring that MVC into another project by copying just one folder - everything is in one place instead of spread around model, view and controller folders.
ME is different from Matchbox because you can nest those modules. So, from another controller, you can get some of the nice output from the original, tidy MVC set without calling a controller via URI (i.e., another http call using file_get_contents() or curl). You can get controller output without having to go out through the http interface again.
Modular HMVC means modular MVC triads. Matchbox and Modular Extensions allows related controllers, models, libraries, views, etc. to be grouped together in module directories and used like a mini application. But, ME goes one step further and allows those modules to “talk” to each other.
Note:
You can find more FAQ at the wiki page Modular Extensions - FAQ
Features:
All controllers can contain an $autoload class variable, which holds an array of items to load prior to running the constructor. This can be used instead of module/config/autoload.php, however using the file takes precedence over the class variable.
Modules::run() output is buffered, so any data returned or output directly from the controller is caught and returned to the caller. In particular, $this->load->view() can be used as you would in a normal controller, without the need for return.
Controllers can be loaded as class variables of other controllers using $this->load->module(’module/controller’); or simply
$this->load->module(’module’); if the controller name matches the module name.
Any loaded module controller can then be used like a library, ie: $this->module_controller->do_stuff(), but it has access to its own models and libraries independently from the caller.
Module controllers can have independent methods, located in a module/methods directory, these methods act as libraries extending their parent controller and have access to the parent controller features.
Loading a method is achieved from a module controller by using $this->load->method(’method’); or from a view by using modules:run(), if the method name is not defined in the controller then the method subclass will be loaded and its own index() method will be called, however if the controller actually has the method, it will be called as normal.
Controllers also have a instance() method that can be used instead of get_instance() in libraries and helpers etc.
ie: $ci = controller::instance();
Of course all module controllers are accessible from the URL via module/controller/method or simply module/method if the module and controller names match.
However if you add the _remap() method to your controllers you can prevent unwanted access to them and redirect or flag an error as you like.
Download
Download new version 4.2: File:modular extensions 4206.zip
Note: Version 4.2 is not backward compatible with version 4.0
View Partials
Your modules output will be buffered by the modules::run() function and the explicit return used in earlier versions is no longer required.
Using a Module as a view partial from within a view is as easy as writing:
<?php echo modules::run('module', $data, 'method') ?>
The $data and ‘method’ above are optional. The default method is index.
Tips and Tricks:
Using language files
application/modules/home/language/home_lang.php
Put this in your controller-file:
$this->load->language('home');
On your view-file:
<?php echo $this->lang->line('name');?>
If you want to specify the language of the language-file you are going to use, you can alter the first line in something like:
$this->load->language('home','english');
Using debug
The debug_helper has two debug methods you might like to look at.
debug($any_object); will display the $any_object and list its loaded libraries, using $this will display the current module.
debug_in($any_object) or debug_in($any_array) will do a full dump on the subject.
NOTE:
If you debug_in() the CodeIgniter Core ($CI), you will get a page full of recursive arrays. This is not an issue because most of the recursions are only references back into $CI core objects.
Issues
Do not use the MY_Controller extension in your application/libraries directory. This will cause CodeIgniter to bypass loading Modular Extensions and modules will not function. If you need to run methods in a base controller define them in another module controller and use the controller autoload functionality.
MY_ prefixed resources are not loaded by ME when they are inside the module directory (e.g., MY_directory_helper.php is not loaded when it is in the modulename/helpers directory). This is because ME doesn’t check for MY_ extensions in modules. To get new functionality using helpers, plugins, models, etc… either make a new named file and load that resource or put your MY_ prefixed resource up in the requisite application directory (helpers for a MY_ helper, libraries for a MY_ library, etc…).
NOTE:
Do you get notices or error-messages? You might want to have a look at the wiki page
Modular Extensions - Notices and errors as well.
Category:Contributions -> Libraries -> Miscallenous
