Jingga/Developer-Guide
1
0
Fork 0
mirror of https://github.com/Karaka-Management/Developer-Guide.git synced 2026-01-11 20:38:42 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

implement todos

Browse Source
This commit is contained in:
Dennis Eichhorn 2021-07-15 21:51:30 +02:00
parent adc1a5299e
commit dda7791285
6 changed files with 67 additions and 72 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
basics/language_files.md
View File

@ -36,4 +36,12 @@ It is recommended to create the translations in a spreadsheet software and expor
Afterwards you can import the modified csv file in the OMS exchange which will create the language files based on this file.
> Please note that the csv must be `;` deliminated and `"` escaped.
> Please note that the csv must be `;` deliminated and `"` escaped.
## Import/Export
In order to create translations more easily you may use the OMS language exporter. This exporter generates a csv including all module langauge files. You can use this to easily check which localized string are not implemented in the language file of the respective language.
After you modified the csv file you can import it with the OMS language importer.
Since the import/export is so simple it is actually recommended to use `$this->getHtml('...')` in the `.tpl.php` files without manually generating a language file and only do it in the generated csv file. This option also allows you to use automatic translation tools.

2
example_module/module.md
View File

@ -2,6 +2,7 @@
The following directory structure should roughly visualize how modules are structured. The purpose of the different sub-directories and their files will be covered in the following sections.
```
* {UniqueModuleName}
* Admin
* Install
@ -40,6 +41,7 @@ The following directory structure should roughly visualize how modules are struc
* Controller.php
* Controller.js
* info.json
```
All modules are located inside the `/Modules` directory and their directory name has to be the module name itself without whitespace.

6
general/setup.md
View File

@ -6,7 +6,7 @@ In order to setup the application for development for the first time please see
Make sure your dev-environment or server fulfills the following requirements:
* PHP >= 7.4
* PHP >= 8.0
* PHP extensions: mbstring, gd, zip, dom, mysql/pgsql/sqlsrv, sqlite, bcmath, imap\*, redis\*, memcached\*, ftp\*, socket\*, curl\*, xml\*
* databases: mysql, postgresql, sqlsrv
* webserver: apache2
@ -43,7 +43,7 @@ After the installation you'll have access to the following content:
### Annotation
During this process the database automatically gets dropped (if existing) and re-created. If you don't have `xdebug` installed but `phpdbg` you can replace `php phpunit.phar ...` with `phpdbg -qrr phpunit.phar ...` or use `pcov` for much faster code coverage generation.
During this process the database automatically gets dropped (if it exists) and re-created. If you don't have `xdebug` installed but `phpdbg` you can replace `php phpunit ...` with `phpdbg -qrr phpunit.phar ...` or use `pcov` for much faster code coverage generation in `Build/Inspection/Php/tests.sh`
## Option 2: PHPUnit Test Suits
@ -66,7 +66,7 @@ After the installation you'll have access to the following content:
### Annotation
During this process the database automatically gets dropped (if existing) and re-created. If you don't have `xdebug` installed but `phpdbg` you can replace `php phpunit.phar ...` with `phpdbg -qrr phpunit.phar ...` or use `pcov` for much faster code coverage generation.
During this process the database automatically gets dropped (if it exists) and re-created. If you don't have `xdebug` installed but `phpdbg` you can replace `php phpunit ...` with `phpdbg -qrr phpunit.phar ...` or use `pcov` for much faster code coverage generation.
## Git Hooks (Linux only)

38
standards/documentation.md
View File

@ -44,11 +44,11 @@ A file documentation MUST be implemented in the following form:
*
* PHP Version 7.0
*
* @package Package name
* @copyright Orange Management
* @license OMS License 1.0
* @version 1.0.0
* @link http://your.url.com
* @package Package name
* @copyright Orange Management
* @license OMS License 1.0
* @version 1.0.0
* @link http://your.url.com
*/
```
@ -60,10 +60,10 @@ A class documentation MUST be implemented in the following form:
/**
* Class description.
*
* @package Package name
* @license OMS License 1.0
* @link http://your.url.com
* @since 1.0.0
* @package Package name
* @license OMS License 1.0
* @link http://your.url.com
* @since 1.0.0
*/
```
@ -101,7 +101,7 @@ A function/method documentation MUST be implemented in the following form:
### Variable
Variable documentation is not mandatory and can be omitted. However it's recommended to use a variable documentation for objects and arrays of objects in templates for ide code completion.
Variable documentation is not mandatory and can be omitted. However it's recommended to use a variable documentation for objects and arrays of objects in templates for IDE code completion.
Example:
@ -119,11 +119,11 @@ The javascript documentation is based on JsDoc, therefore only valid JsDoc comme
/**
* File description.
*
* @package Package name
* @copyright Orange Management
* @license OMS License 1.0
* @version 1.0.0
* @link http://your.url.com
* @package Package name
* @copyright Orange Management
* @license OMS License 1.0
* @version 1.0.0
* @link http://your.url.com
*/
```
@ -135,10 +135,10 @@ A class documentation MUST be implemented in the following form:
/**
* Class description.
*
* @package Package name
* @license OMS License 1.0
* @link http://your.url.com
* @since 1.0.0
* @package Package name
* @license OMS License 1.0
* @link http://your.url.com
* @since 1.0.0
*/
```

50
standards/general.md
View File

@ -197,7 +197,7 @@ Most issues should be documented in the code as todo and vice versa.
```php
/**
* @todo Orange-Management/Repository#IssueNumber [issue:information]
* @todo Orange-Management/Repository#IssueNumber
* Below comes the issue/todo description.
* This way developers can see todos directly in the code without going to an external source.
* Todos must not have empty lines in their descriptions.
@ -208,51 +208,3 @@ Most issues should be documented in the code as todo and vice versa.
```
The issue information can be used to provide additional information such as priority, difficulty and type.
### Priority
Structure:
```php
[p:{PRIORITY}]
```
Possible priorities are:
* high
* low
* medium
### Difficulty
Structure:
```php
[d:{DIFFICULTY}]
```
Possible difficulties are:
* first
* beginner
* expert
* medium
Difficulties marked with first are perfect for people who would like to contribute to the project for the first time.
### Type
Structure:
```php
[t:{TYPE}]
```
Possible types are:
* feature
* optimization
* performance
* question
* security
* todo (= default)

33
standards/php.md
View File

@ -26,6 +26,31 @@ This means each class is in a file by itself, and is in a namespace of at least
Class names MUST be declared in StudlyCaps.
### Return type hint
The return type hint must have a whitespace after the closing braces and after the colon. The return type must be on the same line as the closing brace.
```php
function() : int
{
}
```
or for multiline function parameters
```php
function(
$para1,
$para2,
$para3,
$para4
) : int
{
}
```
### Default Functions
Function calls to php internal function calls must use the root namespace `\`:
@ -37,6 +62,14 @@ Function calls to php internal function calls must use the root namespace `\`:
....
```
## Type hints
Type hints are mandatory wherever reasonably possible (member variables, function parameters, return types, ...).
## Attributes
Function attributes must not be used!
## Php in html
Php code embedded into template files SHOULD use the alternative syntax for control structures in order to improve the readability: