Module Manifest - Jet\Application_Module_Manifest
The manifest is the metadata of the module. It is actually the manifest.php file in the module directory. In this file, the metadata is stored classically as an associated field.
The Jet\Application_Module_Manifest class then works with the metadata. Simply put, it is a carrier of summary information about the module. And here again, if you are not comfortable with this class and its implementation, you can make your own manifest class and impose it on the system using factory. The only requirement is that your class must inherit from the Jet\Application_Module_Manifest class.
Now let's see what the manifest can do:
Basic methods
Method | Meaning of |
---|---|
public __construct( ?string $module_name = null ) |
The $module_name parameter is optional and whether or not it is specified has a major impact on the behavior. If the module name is passed to the constructor, the constructor performs the overall initialization. That is, it uses the
Application_Modules::readManifestData( $module_name )
call to retrieve the manifest data, validate it and initialize it.If the parameter has no value, an empty manifest is prepared and initialization is not performed at all. This behavior is necessary for tools that can generate new modules. |
public getName( ): string |
Returns the module name (e.g. Content.Articles.Admin) |
public getModuleDir( ): string |
Returns the full path to the module directory. |
public getModuleInstallDirPath( ): string |
Returns the full path to the module installation directory. |
public getModuleInstallDictionariesDirPath( ): string |
Returns the full path to the module's dictionary installation directory. |
public getNamespace( ): string |
Returns the module namespace. |
public getVendor( ): string |
Returns the vendor / author of the module. This is information obtained from the manifest file. |
public getVersion( ): string |
Returns the version of the module. This is information obtained from the manifest file. |
public getLabel( ): string |
Returns the user-readable name of the module. This is information obtained from the manifest file. |
public getDescription( ): string |
Returns a user-defined description of the module. This is information obtained from the manifest file. |
public isMandatory( ): bool |
Returns indicates whether the module is/is not mandatory and whether it is therefore necessary to install and activate it regardless of the user's will. This is information obtained from the manifest file. |
public isInstalled( ): bool |
Indicates whether the module is/is not installed. |
public isActivated( ): bool |
Indicates whether the module is/is not active. |
ACL - actions and authorization
A module can provide its own set of operations for the authentication and authorization control system to perform, which are to be subject to approval and control by user roles. This set of operations is also referenced by the controller microrouter.
But let's put it simply. Let's assume that the administration module will perform the classic operations: add something, edit something, view something and delete something. And of course, sometimes it is necessary to restrict who can do what (what user, or better what group of users - roles). To this end, Jet has a system of user roles and controls permissions. But the system needs to know what permissions are available - what it should actually allow. And one of the sets of possible permissions are just the ACL actions of the modules. So the aforementioned administration module will have the following in its manifest, for example:
return [
// ... ... ...
'ACL_actions' => [
'get_article' => 'Get article data',
'add_article' => 'Add new article',
'update_article' => 'Update article',
'delete_article' => 'Delete article',
],
];
Method | Meaning of |
---|---|
public getACLActions( bool $translate_description = true, ?Locale $translate_locale = null ): array |
Returns a list of available actions. The method directly translates action descriptions using the translator, but translation can be prevented ($translate_description parameter). It is also possible to specify a specific location for the translator (if not specified, the current one is used). |
public hasACLAction( string $action ): bool |
Indicates whether or not the module has a specific action. |
Compatibility check
The compatibility check is not implemented in the sample application. However, if a complete product with a long lifecycle is built on Jet and perhaps a community sharing modules for such a product, compatibility checking is necessary. However, its implementation is a matter for the application. There are a thousand ways to do this and it is not possible to choose just one. That's why Jet (as a framework) provides the necessary means to do it, but no longer interferes with it itself.
Method | Meaning of |
---|---|
public static setCompatibilityChecker( callable $compatibility_checker ): void |
Sets a callback for compatibility checking. A prototype of such a callback is:
function ( Application_Module_Manifest $manifest ) : bool
|
public static getCompatibilityChecker( ): callable |
Returns an authentication callback. |
public isCompatible( ): bool |
Verifies that the module is compatible using a callback. If it is not set, it always returns true. |
Storage
Method | Meaning of |
---|---|
public toArray( ): array |
Returns the manifest data as an associated array. It is used to store the manifest. |
public saveDatafile( ): void |
Writes the module manifest file. The method does not perform the operation, but calls this:
Application_Modules::saveManifest( $this );
|