mirror of
https://github.com/Karaka-Management/Developer-Guide.git
synced 2026-01-13 21:28:40 +00:00
Added info.json and routes
This commit is contained in:
parent
56d7f181e7
commit
c34d950f38
|
|
@ -7,6 +7,9 @@ The following directory structure should roughly visualize how modules are struc
|
|||
* Install
|
||||
* Navigation.install.json
|
||||
* Navigation.php
|
||||
* Routes
|
||||
* Web
|
||||
* Backend.php
|
||||
* Update
|
||||
* yourUpdateFiles.???
|
||||
* Activate.php
|
||||
|
|
@ -109,6 +112,39 @@ The navigation module is a good example of passing navigation links during insta
|
|||
|
||||
### Deactivate.php
|
||||
|
||||
### Routes
|
||||
|
||||
In the routes directory all application routes are stored. These routing files get used during the installation process of every module and are stored in an application specific routing file. The first directory level contains the directories of the application type `Web`, `Socket` and `Console`. Inside these directories the routing files for the applications are stored by the name of the application e.g. `Backend.php`. The routing files themselves look like this:
|
||||
|
||||
```
|
||||
<?php
|
||||
|
||||
use phpOMS\Router\RouteVerb;
|
||||
|
||||
return [
|
||||
'^.*/backend/admin/settings/general.*$' => [
|
||||
[
|
||||
'dest' => '\Modules\Admin\Controller:viewSettingsGeneral',
|
||||
'verb' => RouteVerb::GET,
|
||||
],
|
||||
],
|
||||
|
||||
'^.*/api/admin/module/status.*$' => [
|
||||
[
|
||||
'dest' => '\Modules\Admin\Controller:apiModuleStatusGet',
|
||||
'verb' => RouteVerb::GET,
|
||||
],
|
||||
[
|
||||
'dest' => '\Modules\Admin\Controller:apiModuleStatusUpdate',
|
||||
'verb' => RouteVerb::SET,
|
||||
],
|
||||
],
|
||||
];
|
||||
|
||||
```
|
||||
|
||||
The routes are defined via regex. One uri can have multiple destinations depending on the request type/verb. It's also possible to have multiple destinations for the same verb in case other views need to be loaded for the same uri (e.g. view injection in order to extend modules).
|
||||
|
||||
## Img
|
||||
|
||||
All module specific images (not theme specific images). E.g. Module preview images showing when searching for modules.
|
||||
|
|
@ -155,4 +191,130 @@ All other language files are optional and usually are only required by other mod
|
|||
|
||||
## Controller.js
|
||||
|
||||
## info.json
|
||||
## info.json
|
||||
|
||||
The `info.json` file contains general module information used during installation as well for identification and display in the module database.
|
||||
|
||||
```
|
||||
{
|
||||
"name": {
|
||||
"id": {UniqueModuleId_INT},
|
||||
"internal": "{UniqueModuleId_STR}",
|
||||
"external": "{Readable module name}"
|
||||
},
|
||||
"version": "{Version}",
|
||||
"requirements": {
|
||||
"phpOMS": "{Version}",
|
||||
"phpOMS-db": "{Version}"
|
||||
},
|
||||
"creator": {
|
||||
"name": "{Creator name/organization}",
|
||||
"website": "{Creator website}"
|
||||
},
|
||||
"description": "{Module description}",
|
||||
"directory": "{UniqueModuleId_STR}",
|
||||
"dependencies": {},
|
||||
"providing": {
|
||||
"Navigation": "{Version}"
|
||||
},
|
||||
"load": [
|
||||
{
|
||||
"pid": [
|
||||
"{SHA1_Uri_hash}"
|
||||
],
|
||||
"type": 4,
|
||||
"for": "Content",
|
||||
"file": "{UniqueModuleId_STR}",
|
||||
"from": "{UniqueModuleId_STR}"
|
||||
},
|
||||
{
|
||||
"pid": [
|
||||
"{SHA1_Uri_hash}"
|
||||
],
|
||||
"type": 5,
|
||||
"from": "{UniqueModuleId_STR}",
|
||||
"for": "{UniqueModuleId_For_STR}",
|
||||
"file": "{UniqueModuleId_For_STR}"
|
||||
},
|
||||
{
|
||||
"pid": [
|
||||
"{SHA1_Uri_hash}"
|
||||
],
|
||||
"type": 5,
|
||||
"for": "Content",
|
||||
"file": "{UniqueModuleId_STR}",
|
||||
"from": "{UniqueModuleId_STR}"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Name
|
||||
|
||||
The name category contains the names used for internel as well as external identification. Both `id` and `internal` are globally unique between all modules and is assigned generated by Orange Management. The `id` can also be used by other modules which need integer identification of modules. The `id` has the form `xxxxx00000` which means, that modules don't only occupy a singl id but a range of ids. This can be usefull for other modules where additional module specifc information need to be assigned (e.g. `Navigation` module). The `external` name is the name the creator of the module can give the module. This is the name that will be used during searches for modules and shown to customers.
|
||||
|
||||
### Version
|
||||
|
||||
The version is automatically incremented by Orange Management. The version might be used by other modules in order to require a specific version of a module. Versions must follow the following format:
|
||||
|
||||
```
|
||||
major.minor.build = 2.512.19857
|
||||
```
|
||||
|
||||
### Requirements
|
||||
|
||||
The `requirements` are used in order to specify core specific requirements such as the database requirements, framework requirements, third party library regirements as well as potential local software requirements.
|
||||
|
||||
### Creator
|
||||
|
||||
In the `creator` category it's possible to specify the `name` of the creator and the `website` of the creator. Multiple creators are not possible.
|
||||
|
||||
### Description
|
||||
|
||||
In the `description` a markdown description can be specified which will be shown in the module overview. This can be used in order to describe the users what the purpose of this module is and how it workds.
|
||||
|
||||
### Directory
|
||||
|
||||
The `directory` is the directory name of the module which is usually the unique string representation of the module. This is the directory in the modules folder where the module files will be located.
|
||||
|
||||
### Dependencies
|
||||
|
||||
Often modules depend on other modules, these dependencies can be defined in the `dependencies`. The keys contain the unique string representation of the required modules and the value contains the version that is required.
|
||||
|
||||
### Providing
|
||||
|
||||
In the `providing` category modules can specify other modules they intend to extend if they are installed. The keys contain the unique string representation of the module which is getting extended and the value contains the version of the module that is supposed to get extended.
|
||||
|
||||
### Load
|
||||
|
||||
The `load` category contains all the files (controllers, language files) that need to be loaded during the application setup for a specific request uri.
|
||||
|
||||
#### PID
|
||||
|
||||
The `pid` (page identifier) is a sha1 hash of the uri where the `file` is supposed to be loaded. The pid needs to be defined in the following matter (e.g. http://127.0.0.1/en/app/path/sub&some=thing):
|
||||
|
||||
```
|
||||
sha1('apppath');
|
||||
```
|
||||
|
||||
The result of the example hash would result in loading all specified files for requests containing '/app/path'. This also includes requests to any subdirectories.
|
||||
|
||||
#### Type
|
||||
|
||||
The `type` contains the type of the file that needs to be loaded.
|
||||
|
||||
* 5 = Navigation language file
|
||||
* 4 = Module controller
|
||||
|
||||
#### For
|
||||
|
||||
The `for` contains the unique module string representation the file is loaded for. This could be the own module or a thrid party module.
|
||||
|
||||
#### From
|
||||
|
||||
The `from`contains the unique module string representation the file is loaded from. This is the `internal` module name from the top of the `info.json` file.
|
||||
|
||||
#### File
|
||||
|
||||
The `file` contains the name of the file to be loaded. No path or extension is required nor allowed.
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user