Welcome Guest, Not a member yet? Register   Sign In
[split] Modules Supported?

I've inherited a project implementing CI3, and found one of the frustrating limitations to be that I couldn't call controller methods from a different controller.  On first thought this might sound like a bad idea, however the DRY principle promotes the idea that you delegate responsibility to a piece of functionality to a single method or class.  I overcame the problems by implementing Wiredesignz' HMVC, which has proven invaluable in both achieving the above objective but also in introducing modules, and in separating/encapsulating the architecture of features and producing standalone generic features that can be re-used anywhere with a call to a module controller method, and ringfencing models with code based in the same module to avoid implementing models outside of a native module class/method.  This has proved invaluable in terms of code organization and reduction.

Will CI4 support modules?  I know that you are enabling the use of namespaces, but will this translate into the ability for controller-methods to be called from other controllers, and for controller-methods (serving view partials) to be called from views?

More or less - see this blog post, and also the View Cells documentation.

The DRY principle promotes abstraction, which is good, but is not a universal excuse for bad design. The logic you're trying to reuse most likely belongs in a model.

Also, you should be aware that in HMVC in CI3, when you call a controller method from another controller, your controller inherits the scope of the controller you call. I've had this come up a couple of times when I decided to take a shortcut and use Modules::Run() instead of extracting the method into a library or model, then found out that the controller's constructor was resetting some properties used in both controllers.

In the end, it was far easier, safer, etc. to move the method into another class and call it from both controllers, rather than use Modules::Run(). It also makes it significantly more obvious that the method might be accessed from other locations if it's in a library or model.

Theme © iAndrew 2016 - Forum software by © MyBB