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

udpate

Browse Source
This commit is contained in:
Dennis Eichhorn 2022-04-10 13:19:39 +02:00
parent eeebb25e6a
commit a99da4b820
5 changed files with 73 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
frontend/elements/dragndrop/dragndrop.md
View File

@ -7,7 +7,7 @@ Elements can be made drag and droppable which can be helpful to allow users to r
In order to make elements drag and droppable you must define a container which contains all the drag and droppable elements.
```html
<div class="dragcontainer">
<div class="oms-dragcontainer">
</div>
```
@ -16,7 +16,7 @@ In order to make elements drag and droppable you must define a container which c
Elements which should be draggable in the container must be marked with `draggable="true"`.
```html
<div class="dragcontainer">
<div class="oms-dragcontainer">
<div draggable="true">1</div>
<div draggable="true">2</div>
<div draggable="true">3</div>

31
frontend/forms/forms.md
View File

@ -1,9 +1,17 @@
# Forms
Handling data is very important for the application which makes forms and data display very important.
Basically any element that can contain child elements can be a form, this includes `<form>` elements but also elements which are marked as form with a data binding `data-tag="form"`. This gives a lot of options as now divs or tables can be used as forms.
**Important:** Every form MUST have an ID defined, if this attribute is not set an element will not get recognized as form, even if it is the `<form>` element itself!
## Bindings
data-tag : tells the element how to behave (e.g. turn none-form elements into forms by defining it as "form")
data-method : method definition for none-form elements (not used for actual forms, where method can be used)
data-method-delete : delete request endpoint if a special endpoint is required
data-marker=tpl : ??? maybe entries which are templates (e.g. inline add or inline edit?) **check**
data-id : Data id (primary id value, by which it is stored in the database)
@ -38,23 +46,24 @@ data-tpl-value-path : remote path for the text
- [x] DragDrop
- [ ] Remote DragDrop
- [x] Remove
- [ ] Remote Remove
- [ ] Remote Remove (easy, only submit data)
- [ ] Remote Update on change (no save button required)
### Heartbeat
- [ ] Remote adds (heartbeat checks)
- [ ] Remote updates (heartbeat checks)
- [ ] Remote removes (heartbeat checks)
### External
- [x] add
- [ ] update
- [ ] remote add
- [ ] remote update
- [x] update
- [x] cancel
- [ ] remote add (easy, only submit data)
- [ ] remote update (easy, only submit data)
### Internal
- [ ] add
- [ ] update
- [ ] remote add
- [ ] remote update
- [ ] cancel
- [ ] remote add (easy, only submit data)
- [ ] remote update (easy only submit data)
### Heartbeat (not form specific)
- [x] Remote adds (heartbeat checks)
- [x] Remote updates (heartbeat checks)
- [x] Remote removes (heartbeat checks)

1
general/first_steps.md
View File

@ -5,6 +5,7 @@ After you installed the application and configured your development environment
Please note that besides the general development guide the organization also provides various other organizational documents which help to understand the processes, development status and decisions made.
* [Development process](https://github.com/Karaka-Management/Docs/blob/master/Processes/Development.md)
* [Code inspection]({%}?page=quality/inspections)
* [Project status](https://github.com/Karaka-Management/Docs/blob/master/Project/PROJECT.md)
* [Code of conduct](https://github.com/Karaka-Management/Docs/blob/master/Policies%20%26%20Guidelines/Code%20of%20conduct.md)
* [Conflict of interest](https://github.com/Karaka-Management/Docs/blob/master/Policies%20%26%20Guidelines/Conflict%20of%20Interest%20Policy.md)

6
general/setup.md
View File

@ -22,8 +22,10 @@ Which IDE or editor a developer uses is up to the individual developer. From exp
## Application install options
1. Option: Only installs the application, due to the large amount of data takes some time to execute. **Recommended**
2. Option: Only installs the application with some tests. Requires you to install the dev tools in advance. **Recommended**
Option 1 and 2 require you to install the dev tools in advance!
1. Option: Installs the application (with a lot of dummy data, this may take a long time). **Recommended**
2. Option: Installs the application (with or without performing tests). **Recommended**
3. Option: Full installation, code checks/tests, generating documentation. **Not recomended**
### Option 1: Demo Application

62
quality/inspections.md
View File

@ -1,6 +1,15 @@
# Code Inspections & Tests
Code inspections are very important in order to maintain the same code quality throughout the application. The `Build` repository and package managers such as `composer` and `npm` contain all essential configuration files for the respective inspection tools. The framework and every module will be evaluated based on the defined code and quality standards. Only code that passes all code, quality and test standards are accepted. Updates and bug fixes also must follow the standards.
Code inspections are very important in order to maintain the same code quality throughout the application. The `Build` repository and package managers such as `composer` and `npm` contain all essential configuration files for the respective inspection tools. The framework and every module will be evaluated based on the defined code and quality standards. Only code that passes all code, quality and test standards is accepted. Updates and bug fixes also must follow the standards.
## Summary
The following tests must pass without errors, failures and warnings for successful code changes:
* `php ./vendor/bin/phpstan analyse --autoload-file=phpOMS/Autoloader.php -l 9 -c Build/Config/phpstan.neon ./`
* `php ./vendor/bin/phpcs ./ --standard="Build/Config/phpcs.xml"`
* `npx eslint ./ -c Build/Config/.eslintrc.json`
* `php ./vendor/bin/phpunit -c tests/PHPUnit/phpunit_no_coverage.xml`
## How and what to test?
@ -18,6 +27,17 @@ The following testing requirements must be met:
When testing it makes sense to test for the happy path/branch of how a method should work and to `try` and break things by trying to find inputs and paths which may lead to unexpected behavior and errors.
### Test locations
* Application: tests
* Php framework: phpOMS/tests
* Modules: Modules/**/tests
* Js framework: jsOMS/tests
* C++ framework + tools: cOMS/tests
* Css framework: cssOMS/tests
* Configurations for tools: Build/Config
* Inspection script: Build/Inspection/inspection.sh
### Unit tests
The smallest/lowest level of testing are the unit tests. Unit tests should be implemented for models and framework methods. Every public function should be covered by at least one unit test. If a method has multiple branches every branch should be covered by a separate unit test. In some cases it might make sense to cover multiple branches in one unit test/test function, such a decision should however be made consciously.
@ -44,6 +64,28 @@ Every module must implement the following tests if applicable:
You can find an example in the TestModule.
### Demo test
The demo application is a simple way to check the overall functionality of the application and provide a user with a large amount of data for manual tests.
A good way to setup a demo application with mostly randomly generated user input data is the **demoSetup** script which can be found in the repository https://github.com/Karaka-Management/demoSetup.
The following command will create a demo application:
```sh
php demoSetup/setup.php
```
In some cases code changes may require changes to the demo setup script (e.g. changes in the api, new modules). Since the demo setup script tries to simulate user generated data it takes some time to run. You may speed up the runtime by parallelizing the execution. However, this may use up 100% of your CPU and storage performance.
```sh
php demoSetup/setup.php -a 0
```
### UI tests
While UI tests can be part of unit, integration or system tests the `cssOMS` repository also includes a simple test suit at http://127.0.0.1/cssOMS/tests/app which allows developers to test UI elements and check how they work.
## Test documentation
* every test must have a short test description
@ -110,7 +152,7 @@ The javascript testing is done with jasmine. The javascript testing directory is
The js code base has a defined code style standard. The easiest way to check for most rules is to run eslint.
```sh
npx eslint jsOMS/ -c Build/Config/.eslintrc.json
npx eslint ./ -c Build/Config/.eslintrc.json
```
> Many IDEs allow to integrate eslint rules/configuration files for automatic checks in the editor
@ -144,18 +186,6 @@ php TestReportGenerator/src/index.php \
--version 1.0.0
```
## Demo setup
## References
A good way to setup a demo application with mostly randomly generated user input data is the **demoSetup** script which can be found in the repository https://github.com/Karaka-Management/demoSetup.
The following command will create a demo application:
```sh
php demoSetup/setup.php
```
In some cases code changes may require changes to the demo setup script (e.g. changes in the api, new modules). Since the demo setup script tries to simulate user generated data it takes some time to run. You may speed up the runtime by parallelizing the execution. However, this may use up 100% of your CPU and storage performance.
```sh
php demoSetup/setup.php -a 0
```
[Development process](https://github.com/Karaka-Management/Docs/blob/master/Processes/Development.md)