Welcome Guest, Not a member yet? Register   Sign In
Poll: CI4: Module support?
You do not have permission to vote in this poll.
115 88.46%
6 4.62%
9 6.92%
Total 130 vote(s) 100%
* You voted for this item. [Show Results]

Module support?

(This post was last modified: 06-07-2015, 07:51 AM by ivantcholakov. Edit Reason: A typo )


I agree with you, but with one exception. CodeIgniter 4 needs to make a radical step, only once, and then to be conservative for a relatively long period. Currently (in CI2, CI3) the "God object" pattern is used, it has to be replaced. I guess, a dependency injection container will be introduced, either a CI-specific development or from another project.

(This post was last modified: 06-13-2015, 02:04 AM by nasser.man.)

Fuelphp is a good framework based on codeigniter, it has many nice goodies like supporting modules or presenters, i wish codeigniter develop and planner team looks at it, ( and kohana). This frameworks are good as ci, easy to learn and easy to use, is it possible use some ideas or code from them in ci4?
CI is nice Heart

I am just finishing a website (quite complicated paid for app) using HMVC for the first time. I really went over the top initially with the modular conception and had to rewrite when quite honestly it became just tedious and long winded. I have since rewritten virtually the entire app to remove much of the HMVC architecture. It seemed like a good idea at the time. However, now the app is nearly complete I am finding myself once again rewriting huge numbers of files as test users provide feedback and I kinda wish I had stuck with pure HMVC in the first place.

Personally, and after this recent experience, I feel that the idea of a controller calling a controller is completely right, justified and in many cases absolutely essential to prevent the duplication of code.

However, in retrospect, I think the entire problem was due to the reality that as much as you think you know and have planned for the specifications of your app, the truth is that goal posts shift, that requirements change, and that users are fickle beasts that cannot be tamed.

So, my next project similar to this will definitely be HMVC all the way, despite the extra legwork involved, despite the lack of immediacy of code responsibility, despite the extra coding, because in the long run, it IS the most efficient and manageable method to code in complex, changing environments.

But, for Codeigniter, and this is not for me to decide, whether to include HMVC or modular architecture by default seems to depend, IMHO, on the target audience. The problems I have encountered do not usually happen in simple online shops, or blogs, or simple CRUD administrative backends. It only really occurs in complex user applications that require a large amount of user flexibility and choice.

Personally, I don't think Codeigniter can work for all audiences. And so perhaps the time has come to define exactly who the target audience is. To say 'everyone' is simply unrealistic. Perhaps for the app I mentioned earlier, CI was not the best choice. Perhaps, knowing who the target audience is, will answer many questions about such things like composer or HMVC.

So who is the target audience for CI4? Currently I have no idea.


Everyone. http://forum.codeigniter.com/thread-61371.html

(06-22-2015, 07:22 PM)PaulD Wrote: Personally, and after this recent experience, I feel that the idea of a controller calling a controller is completely right, justified and in many cases absolutely essential to prevent the duplication of code.

Can you give specific examples of why controllers call other controllers?


(This post was last modified: 06-24-2015, 07:55 AM by sintakonte.)

actually i can give you an example

i'm  working on a B2B solution which is developed in CI;
This shop contains multiple subshops which are consistently quite different to each other (therefore we needed separate modules for each subshop)- and this is the reason why i'm so much in love with HMVC - We have developed our own cart solution as a module and every shop calls the cart controller in the same way to geht the cartview;
(below an excerpt for one of our views and those controllers which are involved)

In this instance you've 2 possibilities:

1. to call the module in the view like 
PHP Code:
<div role="tabpanel" class="tab-pane active" id="add-to-cart">

2. or to call the module in the specific modules controller and pass the result to the view 
PHP Code:
class Ekf extends Modules_Controller
    public function 
    public function 
$objItem $this->EkfShopItem_Model->getItem();
$arrNosSnsCategories $this->NosSns_Model->getCategories($this->mer->isHeadDebitor());
$strViewCart modules::run("Cart/displayCartForEkfShopItem",$objItem);
$arrData = array(
"objCat" => $objCat,
"arrNosSnsCategories" => $arrNosSnsCategories,
"strViewCart" => $strViewCart
"objItem" => $objItem

and the view looks like
<div role="tabpanel" class="tab-pane active" id="add-to-cart">
    <?=$strViewCart; ?>

and the Cart Module looks like

PHP Code:
class Cart extends Modules_Controller

 public function 

 public function 
displayCartForEkfShopItem(EkfShopItem_Object $obj)
$objCartWrapper $this->Cart_Model->loadWrapper($this->mer->getCurrentActiveMerchant()->No_);

$arrData = array();
$arrData["objShop"] = $obj;
$arrData["objCart"] = $objCartWrapper->loadCart("ekf"$obj->saison);



What sintakonte has written is a very good illustration.

1. IMO the first possibility is to be preferable, and I use it mostly.

2. The second possibility makes sense in very specific cases, generation of automatic email messages for example. I can identify two main disadvantages for ordinary cases:
- HTML is generated by the sub-controller, then it is returned to the main controller, then it is passed to the main view to be inserted somewhere there. This is waste of memory and performance;
- Code of the main controller is polluted with additional code, making it not clean for reading and in some cases future changes might need corrections within the main and the sub- controllers.

The second possibility I think is what people call "controller calls a controller", and they are right about criticizing it. But it does not mean that there is something wrong with HMVC - apply preferably the first possibility and code will be fine.

(This post was last modified: 06-24-2015, 08:41 AM by sintakonte.)


your example with the auto mail generation is very good
We developed our own mail module and use it like (again a code excerpt)

PHP Code:
        $objMailLayout = new MailLayout_Object();

$objMail = new Mail_Object();

$arrReplyMailerData modules::run("mail/mailing/send",$objMail); 

 - most of the time you will call the mail module from one of your action models - but it can happen to use it in one of your controllers of course.

I simply don't see how to avoid frustration if you don't use HMVC Wink
The encapsulation is very clear and pretty much straight forward - if you've a bug or something went wrong - you know exactly where to look.
You avoid duplicate code fragments and all the modules have the same structure as the standard controller system in CI - the recognition value is very high and your learning curve is very low because of that. Of course you can develop your own libraries - but i feel myself much safer in an organized environment like the module system does.

I'm a huge proponent of module use, myself. But also very much against the "controller calling controller" method that WireDesignz' code uses due to the possibility of a confusion of what "$this" means in the different contexts (since "$this" is simply an instance of the calling controller).

It seems to me you could use a library from another module to get the same results without the potential issues with controller calling controller.

(This post was last modified: 06-24-2015, 09:48 PM by ivantcholakov. Edit Reason: A typo )


In pure CI3 $this within a controller context means the controller itself, $this within a view context means the loader class instance. I don't see a difficulty for understanding this concept, it is already being in use.

An additional library... No, thanks. As a rule, I don'want to write libraries with methods that return HTML output. I want to use MVC triads as visual widgets that I can simply put within the views wherever I want. Actually, it is often a designer to do these visual changes within the views only, without touching controllers, libraries or other programmer's stuff.

A reference to a talk that is close to this one: http://forum.codeigniter.com/thread-61509.html

Theme © iAndrew 2016 - Forum software by © MyBB