mirror of
https://github.com/Karaka-Management/Developer-Guide.git
synced 2026-01-11 12:28:41 +00:00
Started w. spellingfixes and doc extension
This commit is contained in:
parent
87f95c0020
commit
2e0d1af3f4
|
|
@ -1,6 +1,7 @@
|
|||
# Summary
|
||||
* [Introduction]({%}?page=README)
|
||||
* [Application Structure]({%}?page=application/structure)
|
||||
* [Application Sample]({%}?page=application/sample)
|
||||
|
||||
## Setup
|
||||
* [Installation]({%}?page=setup/installation)
|
||||
|
|
|
|||
|
|
@ -1,20 +1,16 @@
|
|||
# Application Structure & Flow
|
||||
|
||||
The user request gets passed through the entire application to all modules. The same goes for the response which gets created at the beginning and passed through the application to be filled. The `WebApplication` automatically forwards the user request to the correct application e.g. `Backend`. Inside the application the user request gets routed and the routes are forwarded to the dispatcher which resloves the routes.
|
||||
The user request gets passed through the entire application to all modules. The same goes for the response which gets created at the beginning and passed through the application to be filled. The `WebApplication` automatically forwards the user request to the correct application e.g. `Backend`, `Api`. Inside the application the user request gets routed and the routes are forwarded to the dispatcher which resolves the routes.
|
||||
|
||||
The routes usually reference endpoints in the module `controllers` which collects the model data through the model `mapper` and creates a partial response `view` with an assigned `template` and the collected model data.
|
||||
|
||||
<div align="center">
|
||||
|
||||

|
||||
|
||||
</div>
|
||||

|
||||
|
||||
In the following only the WebApplication and Application are mentioned as the other components are explained in detail in their respective documentation.
|
||||
|
||||
## WebApplication
|
||||
|
||||
The `WebApplication` has a very limited purpose. It only initializes the user request and the empty response object. Additionally the WebApplication also initializes the `UriFactory` based on the user request and forwards the request to the corcect application. The result of the application is finally rendered in the WebApplication.
|
||||
The `WebApplication` has a very limited purpose. It only initializes the user request and the empty response object. Additionally the WebApplication also initializes the `UriFactory` based on the user request and forwards the request to the correct application. The response of the application is finally rendered in the WebApplication.
|
||||
|
||||
## Application
|
||||
|
||||
|
|
|
|||
0
basics/hooks.md
Normal file
0
basics/hooks.md
Normal file
0
basics/language_files.md
Normal file
0
basics/language_files.md
Normal file
|
|
@ -65,7 +65,7 @@ While routes can be added manually to the router it's also possible to import a
|
|||
$this->router->importFromFile($path);
|
||||
```
|
||||
|
||||
The routing file must have the folloing structure:
|
||||
The routing file must have the following structure:
|
||||
|
||||
```php
|
||||
<?php return [
|
||||
|
|
@ -83,4 +83,47 @@ The routing file must have the folloing structure:
|
|||
];
|
||||
```
|
||||
|
||||
In this schematic the first route has different destinations depending on the verb.
|
||||
In this schematic the first route has different destinations depending on the verb.
|
||||
|
||||
## Permissions
|
||||
|
||||
It's also possible to define permissions for a specific application, organization and account in the routes which are then checked if they are set. If they are not set no permissions are checked.
|
||||
|
||||
```php
|
||||
$router->route('foo/bar', RouteVerb::GET, 'APP_NAME', ORG_ID, ACCOUNT);
|
||||
```
|
||||
|
||||
```php
|
||||
<?php return [
|
||||
'{ROUTE_STRING}' => [
|
||||
[
|
||||
'dest' => {CLOSURE/REFERENCE_STRING},
|
||||
'verb' => {VERB_1 | VERB_2},
|
||||
'permission' => [
|
||||
'module' => {MODULE_NAME},
|
||||
'type' => {CREATE | READ | UPDATE | DELETE | PERMISSION},
|
||||
'state' => {MODULE_SPECIFIC_IDENTIFIER_FOR_THE_PERMISSION},
|
||||
],
|
||||
],
|
||||
[
|
||||
'dest' => {CLOSURE/REFERENCE_STRING},
|
||||
'verb' => {VERB_3},
|
||||
],
|
||||
],
|
||||
'{ANOTHER_ROUTE_STRING}' => [ ... ],
|
||||
];
|
||||
```
|
||||
|
||||
### Module Name
|
||||
|
||||
The module name has to be the name specified by the module. This can be found in the `info.json` or the `Controller` of the module.
|
||||
|
||||
### Type
|
||||
|
||||
The different permission types can be found in the `PermissionType` class/enum.
|
||||
|
||||
### State
|
||||
|
||||
This value is module specific and needs to be defined by every module individually.
|
||||
|
||||
The state allows a module to have different permissions. E.g. a news module has permissions for managing news articles (CRUDP), at the same time it also has permissions for managing tags/badges (CRUDP). Just because a user has permissions for managing news articles this user may not need to have the same permissions for managing tags/badges.
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ The date/time is versatile and can have multiple formats. By default the localiz
|
|||
* long
|
||||
* very_long
|
||||
|
||||
Other formats are beyond the scope of the localization and must be hard coded. Please be cautios when to hard code the formatting and pay attention to potential confusion for different localizations.
|
||||
Other formats are beyond the scope of the localization and must be hard coded. Please be cautious when to hard code the formatting and pay attention to potential confusion for different localizations.
|
||||
|
||||
In the database only the ISO 8601 format will be used.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ $log->error(FileLogger::MSG_FULL, ['message' => 'Log me!']);
|
|||
|
||||
## File Logging
|
||||
|
||||
The file logging should only be used for database and application problems. The file logging is part of the framework and is always available. The file logger implements the singleton pattern and can be aquired by calling the `getInstance()` function.
|
||||
The file logging should only be used for database and application problems. The file logging is part of the framework and is always available. The file logger implements the singleton pattern and can be acquired by calling the `getInstance()` function.
|
||||
|
||||
```php
|
||||
$log = FileLogger::getInstance('logging/path', false);
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Uri
|
||||
|
||||
The `UriFactory` is used in order to build URIs. The factory generates the URIs based on a raw uri as well as defined parameters and placeholders. The uri factory is available for the backend as well as the frontend and operate mostly the same and provide similar functionlity.
|
||||
The `UriFactory` is used in order to build URIs. The factory generates the URIs based on a raw uri as well as defined parameters and placeholders. The uri factory is available for the backend as well as the frontend and operate mostly the same and provide similar functionality.
|
||||
|
||||
## Parameters
|
||||
|
||||
|
|
@ -29,6 +29,7 @@ It is possible to simply use the current uri and simply append parameters if you
|
|||
Some default parameters can be used for easier use.
|
||||
|
||||
* /base = base uri (e.g. http://www.yoururl.com/basepath)
|
||||
* /path = current uri path without base path (e.g. /your/current/path)
|
||||
* /scheme = current scheme (e.g. http)
|
||||
* /host = current host (e.g. www.yoururl.com)
|
||||
* /lang = current language (e.g. en)
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ The following extensions are recommended for tests and in some cases required by
|
|||
|
||||
## Linux Shell Script
|
||||
|
||||
This is the prefered way to install the application since this also installs all required dev tools and sets up the direcetory structure by itself. Using this method also tears down previous installs for a fresh install perfect for re-installing from the current development version. Furthermore the use of phpUnit also makes sure that the application is working as intended. The phpUnit install also provides lots of dummy data for better integration and functionality testing of your own code/modules.
|
||||
This is the preferred way to install the application since this also installs all required dev tools and sets up the directory structure by itself. Using this method also tears down previous installs for a fresh install perfect for re-installing from the current development version. Furthermore the use of phpUnit also makes sure that the application is working as intended. The phpUnit install also provides lots of dummy data for better integration and functionality testing of your own code/modules.
|
||||
|
||||
### Steps
|
||||
|
||||
|
|
|
|||
|
|
@ -101,7 +101,9 @@ class Test
|
|||
Always use a whitespace before the parentheses.
|
||||
|
||||
```php
|
||||
while (true) { ... }
|
||||
while (true) {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
## If, while, for, foreach, switch
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user