Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Regarding modules
  • Hello there,

    Here I have modules like following.


    Can B module call A controller module?

    I am trying something like this, but, I am getting error.


    The error message says non-static method should not be called statically.

    Yes, I know that method is not static method.
    So, should I make it static method in order to make a module?

  • HarroHarro
    Accepted Answer
    You should never call other modules like that, that will create a tight coupling between the two, and makes it no longer modules.

    Further more, modules are frontend code (controllers, models, views), support classes should go into a package (which can be called from anywhere).

    If you have a legitimate need for a cross-module call, you should use an HMVC request, in a try/catch block that catches HttpNotFoundException (so you can capture the HMVC url failing).
  • Thank you very much for your explanation.

    I will use an HMVC request with try/catch block.

    Thanks :)
  • And in case I need to use models, use \ module :: load ('module'); is it a good option?
    I have a module named product, and inside that module I have created a folder called repository, and all the custom querys I make inside the product repository, and when I need to use this repository in another module I use \ module :: load ('product '), is it a good way?

  • The same remark applies.

    If you want to "modularize" your application/backend code, use packages, not modules. Only use modules for your frontend code, so controllers, views, and everything else that needs to be contained by that module.

    Having said that, the same remark also applies for the coupling issue, as in both cases you create a tight coupling, meaning you can't remove the module or the package without your application crashing.

    This is why the safest method is using an HMVC call, as that allows you to capture the not-found situation.

    And having said that, in the end it is your application, from a technical point of view all options work. This has always been a cornerstone in Fuel development, the framework should never dictate the developer how to solve a specific issue.
  • Thank you very much for you explanations, it helped me a lot.
    Somethings need to be changed in my aplication (:.

    Thank you
  • It doesn't have to, it is entirely up to you. If you're not to bothered with re-use and dependencies, who cares?
  • That's right.

    Thanks for your additional explanation :)

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion