Application modules

Modules and modularity, concepts that run throughout Jet like a red thread, as you already noticed when reading the documentation. Yes, I really like modularity and it has always proven itself in practice and has brought only positives. But what exactly is modularity? What is it good for? Why and how to "chunk" the application? There can be different views on this. So first I would like to clarify how modularity is understood in the world of applications built with the help of PHP Jet.

What is modularity?

It may be an abstract concept, but in reality it is all around us. Everything around us consists of some sub-parts, basic building elements, but they are interconnected, able to work together and form one functional whole. Example? How about a car? It has an engine module, axle modules, brake system module, electronics module (consisting of a series of modules). Or a computer (whether it's a good old PC or a smartphone - it's still a computer). Yes, computers... However, just look at Von Neumann's scheme. A computer is a modularity in itself (processor, memory, controllers, ...). But even our own body is modular. Every organ is a module, every limb is a module. Even human society is modular and each of us plays a role in it (we ourselves are modules). So modularity (in the sense of a whole made up of building elements) is something completely natural and we see it at every step. And so it is natural to make applications in this way as well. That is, to think about applications as a whole, which is made up of individual building elements. It has a number of huge advantages.

Advantages of modularity

• Clarity
  If you design the application well, it will always be clearer than if everything is, so to speak, in one pile.
• Organization of work
  "Franto, please, I need to edit the view of the shopping cart pop-up window. I am sending the graphics. You can find it in the Shop.ShoppingCart module and it is the popup_content view. Thanks!” This is very important when working in a team. Whether it's a small team or a company with dozens of projects and a bunch of employees, it's always important to communicate and organize work easily and efficiently. And modularity and the correct design of the application architecture go directly against this.
• Code reusability
  You already have a quiz module for your CMS, so you can certainly use it on the next project where the client wants quizzes. You just copy the directory from another project and then fine-tune the view (and possibly other things) according to the client's wishes. That you don't have to do it again is clear. But most importantly, you don't even have to prepare it and from all possible places and directories. You simply use and modify the module, which is in one directory - without complicated searching.

Jet application modules

As I already mentioned, the topic of modularity comes up often in Jet. Autoloader has its modules, cache has its backends as modules and so on. That's also modularity, but it's not the modularity we're going to talk about here. As you can already guess from the chapters on MVC , the application module is something more.

It can be said that application modules are micro-applications together forming the whole application, and Jet provides a basic ecosystem for these micro-applications and ensures their basic integration.

Before we continue, please emphasize one important thing . It might seem that modules for Jet applications are intended to be general purpose. That is, Pepa creates some module for Jet application X and Franta can automatically use it in her application Y, which is completely different. That's not how it's meant to be. Jet provides a basic level, basic ecosystem and basic integration. And something more is expected to emerge above the Jet. For example, a Jet Shop e-commerce system fully built on Jet is under development. And Jet Shop has another level of ecosystem, another level of integration. Jet Shop already has its API, its classes, its library. Yes, it's all built on Jet and uses what Jet has to offer. But it's already a big superstructure. And only here in this level it can be assumed that Pepa will develop a module for the Jet Shop and Franta will use it. This is already the right level for such considerations. In the same way, your e-commerce solution, your CMS or anything else can be created and then you can operate with the modules as expected. But they will always be modules for a specific solution, for a specific system. It is not intended that there should be portable modules for the bare Jet. Not that it's not technically possible, but that's not the goal and the point.

What modules can do

• Installation / uninstallation
  Modules can be installed and uninstalled. A module can have its own install/uninstall scripts.
• Activation / deactivation
  For example, modules can be left installed but temporarily disabled.
• Meta information and the manifest
  The module carries information about itself in the form of a manifest . Part of this information can be a common thing like a description of the module, but also, for example, a set of ACL operations for the authorization system . You can further expand this set of information in your applications and systems.
• Custom classes
  A module can carry its own classes. On the contrary, it must even carry at least one class marked as main - the Main class inheriting from Jet\Application_Module . But in addition to this main class and also controllers, it can have other classes that the module needs (and which are not needed for other modules and parts of the application!)
• Own namespace
  As we will show in a moment, each module has its own namespace, the name of which is determined precisely by the given concept.
• Custom page definitions
  We have already come across this in the MVC topic . The module may provide additional page definitions. This is used in practice mainly for modules intended for administration and the like.
• Custom definition of menu items
  Just as a module defines pages, it can provide definitions for menu items . Again, this is used in practice mainly for modules intended for administration and the like.
• Custom view scripts
  Of course, in addition to controllers, the module also needs its own view scripts.
• Custom data
  If the module needs some of its data for its work, these can also be stored in its directory.
• Modules can work together
  One module can get an instance of another module (more precisely, its main class Main)) and continue to work with it (of course, after checking the availability of the given module). So there can be, and in actual practice often is, a connection between the modules. Ideally, the binding should not be too tight (it should be taken into account that the required module is not available). But the interconnectedness of modules is a common and desirable thing.
• Modules may be marked as mandatory
  The module may be marked as mandatory. This means that it must always be installed.

Location, layout, namespaces, and module names

By default, modules are in the ~/application/Modules/ directory. Each module has its own directory. But watch out! Directories can dive. This is very important and thanks to this it is possible to group the modules thematically. I highly recommend it. So a directory in the modules directory does not automatically represent a module, but there may be other subdirectories in it. The module is the directory in which the files manifest.php containing the metadata of the module and Main.php containing the main class of the module are located.

The immersion of directories is not only important for the organization of modules and clarity. Directories and their nesting make up the name of the module as well as the namespace. Let's show it directly on the example of one of the modules of the sample application. As a guinea pig, we will take the directory that is in the directory ~/application/Modules/ Content/Articles/Admin /. This directory is a module named Content.Articles.Admin . So the name of the module exactly corresponds to the directory path. The only difference is that, for practical reasons, slashes (which did not work for me in practice) are replaced by dots. If I want to operate with the module somewhere, I will need this data - its name.

Když v adresáři ~/application/Modules/Content/Articles/Admin/ otevřete třeba skript Main.php (tedy soubor obsahující hlavní třídu modulu), tak uvidíte toto: namespace JetApplicationModule\Content\Articles\Admin; Tedy ano, jmenný prostor všech tříd modulu také odpovídá adresáři. Let's stop at the namespace. It starts with the root namespace of JetApplicationModule. But nothing prevents you from defining your own root namespace for modules via system configuration . On the contrary, it is desirable. When you decide to develop your CMS on Jet, set the root namespace to AwesomeCmsModule (and, of course, please adjust the appropriate loader to the autoloader subsystem).

Thus, the name and depth of the directory where the module is located is the determinant of its name and namespace. Of course, you can rename or copy (clone) modules. Just change the directory and namespace in the module's scripts - in practice this is a trivial and useful operation.

Module structure

Let's not just theorize, so let's reach for one of the modules of the sample application again, namely the Content.Articles.Admin module, which is intended for managing articles in the administration. On this module, let's break down a typical module directory layout.

Also, please take a look at how modules are created, installed, activated , simply how to work with them.