Module support?

Maybe we should all take a step back and remind our selfs what MVC is.

An incoming request is sent to a controller and a method inside this controller is executed.
This called method will use models, libraries, helpers and views to complete the request and return HTML to the output.

Why should HMVC do it any differently? People say a HMVC controller should not return HTML. But if you are going to complete the view outside the called HMVC module, it's not really an independent piece of coding now is it? Saving the returned HTML in a variable in the main controller is no different than saving returned HTML that was completed in the same main controller, or is it?

I think of HMVC as a sort of coding inception. Application within application within application, that all operate independent of each other. Returning the complete result of a request, and not a half finished result of a request to be completed elsewhere.

An HMVC controller responds to a request, just as an MVC controller does. The big difference is the source of the request. In CodeIgniter, the controller gets its request from the Router, as an interpretation of the URL. When you add HMVC on top of that, the controller could get its request from another controller.

One of the things that is difficult to do when working with an HMVC implementation is to keep some separation between controllers or actions which are intended to be used by other controllers and those which are intended to be use to respond to requests from the Router. When people can manage that separation, there is not likely to be any significant harm in returning HTML from a module, as long as that partial view is self-contained (for example, you don't open or close an element which is not contained in the partial view), and the HTML is returned, not output directly by the module.

On the other hand, one of the dangers with generating the HTML in the module is that the module either generates generic HTML which might be more difficult to manipulate with the site's CSS/JavaScript framework, or HTML which is specific to that framework and has to be updated when that framework changes (which means the module knows too much about the site as a whole and isn't truly independent).

In a best case scenario, you might have one controller which responds to the request from the Router, requests partial views and/or data from a number of other controllers, then determines how those partial views will be arranged in the view which it sends to CI's Output.

The example of a shopping catalog as a module and the cart as a module is something I don't get. A shopping cart is part of a shopping catalog. So should that not be a library that is part of the catalog module?

Thats just what I think of it. Maybe I am completely wrong about this.

Before the internet took over just about every form of shopping other than physical storefronts, a shopping catalog was a completely separate entity from a shopping cart. The only place they often co-existed was in catalog stores, which mostly disappeared when I was fairly young (not to mention the catalogs themselves more recently). If you weren't near a catalog store or you didn't mind waiting (and paying) for delivery by mail, you could fill out an order form and mail it or pick up the phone and place an order, either of which never required touching a shopping cart.

What we call a shopping cart on a website is essentially an order form, but they both serve the same purpose. You put stuff in it, and it doesn't really care what that stuff happens to be. It just has to hold that stuff until we either take it out or start the process of actually buying it. In a well-designed system, it very well could be completely separate of not only the catalog, but also anything related to processing the order.

The catalog tells us what we can buy, maybe even gives us some nice pictures to look at and some information about any available options. We make a choice to add something from the catalog to our cart, but the only thing the cart needs to do is remember what choice(s) you made (and really, the data could be dumped into the cart in a format the cart doesn't understand at all, it just has to hold on to it).

One of the reasons this example can work fairly well as an example of HMVC is that we not only want to separate this code logically, we may want to modify the user interface of each of them independently, with neither of them needing to be aware of the changes in the other piece. Ultimately, the controller responding to the request from the Router might put together a page which uses a menu from one controller, a page from a catalog controller, and the user's cart from yet another controller. It might even be dealing with more pieces from other modules which are important to the site displaying the page, but not necessarily the focus of the user's current activity, like maintaining logs and analytics.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide