Module support?

And I would bet that if someone asked WireDesignz to help implement it into CI 4 that he would help out.

What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )

And I would bet that if someone asked WireDesignz to help implement it into CI 4 that he would help out.

Not an option, not least because of personal issues.

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.

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.

@Davcon
well said david.
By the way what's your latest video tuts on codeigniter?

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

@Martin7483: Since you have private messaging disabled, I can't respond to your question directly. However, I will say here that I don't think your approach to HMVC is "wrong", as one of the things I consider a real benefit of CodeIgniter is that you can almost do whatever you want in structuring your application. I do, however, think it's very easy to implement an application using HMVC which gains more problems than benefits from HMVC, and I am as guilty of implementing "bad" HMVC code as anyone else I'm likely to come across.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide

@Martin7483: Since you have private messaging disabled, I can't respond to your question directly. However, I will say here that I don't think your approach to HMVC is "wrong", as one of the things I consider a real benefit of CodeIgniter is that you can almost do whatever you want in structuring your application. I do, however, think it's very easy to implement an application using HMVC which gains more problems than benefits from HMVC, and I am as guilty of implementing "bad" HMVC code as anyone else I'm likely to come across.

That is exactly why I will always be opposed to suggestions for HMVC support in CI.

The amount of people I've seen to know how to use it properly is about 5.
The total amount of people I've seen to actually use it properly is 0.

Just to avoid pointless arguments over this, by the word "properly" above I mean this - creating application modules that are both optional (the application can't depend on them) and independent (the modules themselves can't depend on each other).

@Martin7483: Since you have private messaging disabled, I can't respond to your question directly. However, I will say here that I don't think your approach to HMVC is "wrong", as one of the things I consider a real benefit of CodeIgniter is that you can almost do whatever you want in structuring your application. I do, however, think it's very easy to implement an application using HMVC which gains more problems than benefits from HMVC, and I am as guilty of implementing "bad" HMVC code as anyone else I'm likely to come across.

Looking at the loosely coupled system of CodeIgniter, support for it could and should be added. I do think the added support should not effect how CodeIgniter functions at this moment. Direct routing to a module for example is not needed in my opinion.

I have done this with my Simple HMVC. Only extending the core loader so the ability to use modules is available, but not required.

As for using HMVC properly... Each project is unique, so I do believe an application can depend on a module, but a module should indeed not depend on an application or other modules. But that is my opinion. Agree to disagree I would say

Looking at the loosely coupled system of CodeIgniter, support for it could and should be added. I do think the added support should not effect how CodeIgniter functions at this moment. Direct routing to a module for example is not needed in my opinion.

I have done this with my Simple HMVC. Only extending the core loader so the ability to use modules is available, but not required.

I think you side-stepped a lot of the issues in HMVC by making the "controllers" in your modules not extend CI_Controller (or some replacement class) and not making them routable. In some ways, that enforces the separation between MVC controllers and HMVC controllers, which is good. However, if you don't have the option to create an MVC controller in a module, then a module can't function without an external controller. While that has some benefits, it also starts to degrade the benefits of modular organization of the code.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide

I think you side-stepped a lot of the issues in HMVC by making the "controllers" in your modules not extend CI_Controller (or some replacement class) and not making them routable. In some ways, that enforces the separation between MVC controllers and HMVC controllers, which is good. However, if you don't have the option to create an MVC controller in a module, then a module can't function without an external controller. While that has some benefits, it also starts to degrade the benefits of modular organization of the code.

Isn't that the whole point of HMVC? A request from a higher level controller should be responsible for any module called to complete the required request.
And why is a "controller" in one of my modules not a MVC controller?