PHP Jet Framework

quickly, simply, directly, safely, efficiently
Getting started Documentation Download Contact Discussions

The English version of the documentation has so far only been translated using Google Translate. We are working on proofreading, but the work is in the early stages.

Please be patient. Thank you!

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.

Directory / File Importance
As the name suggests, this is the installation directory of the module.
(You must have noticed the _ character at the beginning of it and as you already know, this directory is not supposed to be on the production environment - just for the record :-) )

The directory may (or may not) contain scripts called during module installation/uninstallation. Everything needed can be done in these scripts. So create database tables, copy dictionaries to the main directory of dictionaries and so on.

In addition to scripts, the directory may contain necessary data for installation (e.g. files that the installation script copies somewhere, etc.).

However, none of the above is mandatory. Installation/uninstallation works even without this directory and scripts.
As already said, the module can define menu items. This sample module defines its items in the administration menu.

Of course, it is not mandatory and the module that does not need a menu does not need to have this directory at all. Likewise, it is not a dogma that the menu must be for administration - on the contrary, the definition can be for whatever is needed.
As you can see, the module defines a page for the admin base , which will be at the URL /admin/articles/ and at this URL the module itself will be available to users.

Again, not every module needs to define any pages, so the directory is completely optional. Likewise, it is not a dogma that the definition of pages should be for the administration.
And here are the view scripts of the module. The demonstration module has a view for the list of articles (list.phtml) and their modification (detail.phtml) in the administration.

None of this is mandatory. What the view module will have and if there is any at all is entirely up to you.
If the module is to be used for MVC , it must have at least one controller class. The default controller is Main, but there can be more controllers.

However, if you are creating a module that will not provide content to pages anywhere and therefore will not need controllers, then of course it does not need to have any controllers.
List.php And another optional thing - only for the purpose of illustration and demonstration of what is possible. As already mentioned, a module can have its own classes. And in this file there is a class to work with the list of articles. If the module has its own classes, they can of course be organized into directories according to the same convention used by the rest of the system.
Main.php This is mandatory . A module must have a class Main that inherits from Jet\Application_Module (or another class that must inherit from Jet\Application_Module ). This class is the main point through which the module can communicate with the rest of the system and with other modules. That is why it is mandatory.
manifest.php A file containing the module's manifest , i.e. its metadata. This is logically mandatory .

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

Previous chapter
Other (simplified) approaches to MVC
Next chapter
Working with modules