Working with modules
In this chapter, we will look at how to work with modules from their creation, through their management (installation, activation) to their use in the application - for example, by another module.
Creating a module
You can create modules completely manually. But in truth.... I really didn't enjoy it. That's why Jet Studio has a module creator. It's a feature that creates a module based on a template. Templates can also be created, but that's a topic outside of this documentation. There are currently two templates available. The first one creates a very basic module structure, the second one can create an entire administration module to manage a data entity. It's best to just try it out.
Installation/deinstallation, activation/deactivation
If you want to install and activate modules, you have two tools at your disposal. The first and recommended one is ("surprisingly") Jet Studio
Attention! Jet Studio can do much more than just activate and install modules. That's far from the only feature. You can "click" almost anything to modules. Including page definitions and menu items.
The other option is to use CLI tools in the ~/_tools/cli/ directory.
But of course you can do it from a script and you can create your own tools. It's actually simple:
Installing a module:
Application_Modules::installModule( $module_name );
Uninstalling a module:
Application_Modules::uninstallModule( $module_name );
Activating a module:
Application_Modules::activateModule( $module_name );
Deactivating a module:
Application_Modules::deactivateModule( $module_name );
Using the module
The most typical use of modules is within MVC. But as we have already discussed, one module can be used by another module. How to do it? It's a good idea to follow a few guidelines and stick to the principles:
Application code that will use another module should take into account that the used module can be deactivated. Therefore, Jet has a method to determine if a module is available.
Another rule is that application code using another module should not create instances of the classes of the module being used directly. While this is technically possible, it violates the principle that a module is an encapsulated microapplication that should be used by other modules via its Main class. It is therefore advisable to access the module instance (more precisely, the module's Main class instance) via the appropriate Jet methods and use the module's functions via this instance. Ideally, the interface that the Main class of the module being used implements is defined in the general classes of the application.
But let's show everything practically. We have the following situation: module A (let's call it Module.A), which has a specific mission in the application and whose class Main implements the JetApplication\Modules_Some_Interface interface and this interface declares the method someMethod() : string. Here is the code of the main Module.A class:
namespace JetApplicationModule\Module\A;
use Jet\Application_Module;
class Main extends Application_Module implements Modules_Some_Interface {
public function someMethod() : string
{
return "Hello world!";
}
}
And then in another part of the application, for example in another module, we can call this method. How to do it? Here's how:
use Jet\Application_Modules;
if(Application_Modules::moduleIsActivated('Module.A')) {
/**
* @var Modules_Some_Interface $module
*/
$module = Application_Modules::moduleInstance('Module.A');
$something = $module->someMethod();
} else {
$something = null;
}
Remember that the code should detect whether the requested module is even active and behave accordingly. And also, with permission, I will reiterate the advisability of accessing the instance of the main module class via the appropriate method, i.e., via Jet\Application_Modules::moduleInstance( $module_name ).
As you can see, the Jet\Application_Modules class is used to work with modules and this is another thing worth exploring.