mirror of
https://github.com/Karaka-Management/Developer-Guide.git
synced 2026-01-11 20:38:42 +00:00
More documentation
This commit is contained in:
parent
c34d950f38
commit
d5371d5a95
17
basics/dispatching.md
Normal file
17
basics/dispatching.md
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
# Dispatching
|
||||
|
||||
The dispatching is the follow up on the routing. In the dispatcher the route destination get resolved and executed.
|
||||
|
||||
The dispatching is fairly simple as it only requires a single function call.
|
||||
|
||||
```
|
||||
$this->dispatcher->dispatch($this->router->route($request))
|
||||
```
|
||||
|
||||
Based on the function definition returned by the router it's possible to pass more parameters to the function such e.g. request and response objects.
|
||||
|
||||
```
|
||||
$this->dispatcher->dispatch($this->router->route($request), $request, $response)
|
||||
```
|
||||
|
||||
The result of the `dispatch` call is an array of results.
|
||||
|
|
@ -0,0 +1,86 @@
|
|||
# Routing
|
||||
|
||||
Routing allows to bind a string representation to a function. This is required in order to execute request specific code segments.
|
||||
Routes are defined in a uniform manner for all different application types such as http, socket or console.
|
||||
|
||||
## Routes
|
||||
|
||||
Routes are defined as RegEx. It is recommended to match the desired route as closely as possible and provide both `^` at the beginning and `$` at the end of the route.
|
||||
|
||||
Resolving a route can be done by providing a request to the router
|
||||
|
||||
```
|
||||
$this->router->route(new Request());
|
||||
```
|
||||
|
||||
or a route
|
||||
|
||||
```
|
||||
$this->router->route('foo/bar', RouteVerb::GET);
|
||||
```
|
||||
|
||||
The result is an array of either string references or closures.
|
||||
|
||||
## Closure
|
||||
|
||||
For routes it's possible to define a `\Closure` which will get returned upon using the specified route.
|
||||
|
||||
```
|
||||
$this->router->add('foo/bar', function() {
|
||||
return 'Hellow World';
|
||||
});
|
||||
```
|
||||
|
||||
Routes can have different verbs which are derived from the HTTP verbs. Routes that get assigned a verb will only be matched if the route and the routing verb match.
|
||||
|
||||
```
|
||||
$this->router->add('foo/bar', function() {
|
||||
return 'Hellow World';
|
||||
}, RouteVerb::GET | RouteVerb::SET);
|
||||
```
|
||||
|
||||
## Route Parameters
|
||||
|
||||
<coming soon>
|
||||
|
||||
## Reference
|
||||
|
||||
Instead of defining closures it's possible to define a string representation of the destination that should be called.
|
||||
|
||||
```
|
||||
$this->router->add('foo/bar', '\foo\controller:barFunction');
|
||||
```
|
||||
|
||||
Static functions can be defined in the following fashion:
|
||||
|
||||
```
|
||||
$this->router->add('foo/bar', '\foo\controller::barFunction');
|
||||
```
|
||||
|
||||
## Import
|
||||
|
||||
While routes can be added manually to the router it's also possible to import a list of routes through the file import function.
|
||||
|
||||
```
|
||||
$this->router->importFromFile($path);
|
||||
```
|
||||
|
||||
The routing file must have the folloing structure:
|
||||
|
||||
```
|
||||
<?php return [
|
||||
'{ROUTE_STRING}' => [
|
||||
[
|
||||
'dest' => {CLOSURE/REFERENCE_STRING},
|
||||
'verb' => {VERB_1 | VERB_2},
|
||||
],
|
||||
[
|
||||
'dest' => {CLOSURE/REFERENCE_STRING},
|
||||
'verb' => {VERB_3},
|
||||
],
|
||||
],
|
||||
'{ANOTHER_ROUTE_STRING}' => [ ... ],
|
||||
];
|
||||
```
|
||||
|
||||
In this schematic the first route has different destinations depending on the verb.
|
||||
|
|
@ -177,10 +177,12 @@ A language file should have the following naming convention:
|
|||
The content of the language file is straight forward:
|
||||
|
||||
```
|
||||
<?php
|
||||
$return [ '{UniqueModuleName}' => [
|
||||
'StringID' => 'Your localized string',
|
||||
]];
|
||||
<?php return [
|
||||
'{UniqueModuleName}' => [
|
||||
'StringID' => 'Your localized string',
|
||||
...
|
||||
]
|
||||
];
|
||||
```
|
||||
|
||||
All other language files are optional and usually are only required by other modules. The navigation module for example requires an extra language file for the navigation elements. This however should be specified in the modules you want to make use of.
|
||||
|
|
|
|||
|
|
@ -16,10 +16,6 @@ The `$id` can be used as primary key. For this member variable no setter method
|
|||
|
||||
The data mapper itself is where all the magic happens, from inserts, updates, to selects etc.
|
||||
|
||||
### Extending
|
||||
|
||||
By default it should extend the `DataMapperAbstract` but it is also possible to extend any other data mapper in case someone wants to extend an already existing data mapper. By default extending another data mapper overwrites its member variables as expected but in many cases it is required to not replace functionality/variables and truly extend it. For this purpose the boolean variable `$overwrite` can be set to false and the data mapper will recognize all variables and configurations.
|
||||
|
||||
### Primary key
|
||||
|
||||
The primary key can be indicated with the variable `$primaryField`. This variable should contain the string representation of the database field name. This variable is compulsory.
|
||||
|
|
@ -68,7 +64,6 @@ With the `$hasMany` variable it's possible to specify other models that belong t
|
|||
protected static $hasMany = [
|
||||
'model_var_name_3' => [
|
||||
'mapper' => HasManyMapper::class,
|
||||
'relationmapper' => HasManyMapper::class,
|
||||
'table' => 'relation_table_name',
|
||||
'dst' => 'relation_destinaiton_name',
|
||||
'src' => 'relation_source_name',
|
||||
|
|
@ -76,7 +71,7 @@ protected static $hasMany = [
|
|||
];
|
||||
```
|
||||
|
||||
The `mapper` contains the class name of the mapper responsible for the many models that belong to this model. The `relationmapper` is a mapper of a relation table, this is only required if the relation table is very complex and an additional mapper is required to select, insert etc the relation. The `table` contains the name of the table where the relations are defined (this can be the same table as the source model or a relation table). If a model is only in relation with one other model this relation can be defined in the same table as the model and this `table` field can be `null`. The `dst` field contains the name of field where the primary key of the destination is defined. The `src` field is only required for models which have a relation table. This field contains the name of the field where the primary key of the source model is defined.
|
||||
The `mapper` contains the class name of the mapper responsible for the many models that belong to this model. The `table` contains the name of the table where the relations are defined (this can be the same table as the source model or a relation table). If a model is only in relation with one other model this relation can be defined in the same table as the model and this `table` field can be `null`. The `dst` field contains the name of field where the primary key of the destination is defined. The `src` field is only required for models which have a relation table. This field contains the name of the field where the primary key of the source model is defined.
|
||||
|
||||
A one to many relation would look like the following:
|
||||
|
||||
|
|
@ -84,7 +79,6 @@ A one to many relation would look like the following:
|
|||
protected static $hasMany = [
|
||||
'model_var_name_3' => [
|
||||
'mapper' => HasManyMapper::class,
|
||||
'relationmapper' => null,
|
||||
'table' => null,
|
||||
'dst' => 'relation_destinaiton_name',
|
||||
'src' => null,
|
||||
|
|
@ -98,7 +92,6 @@ A many to many relation which can only be defined in a relation table looks like
|
|||
protected static $hasMany = [
|
||||
'model_var_name_3' => [
|
||||
'mapper' => HasManyMapper::class,
|
||||
'relationmapper' => null,
|
||||
'table' => 'relation_table_name',
|
||||
'dst' => 'relation_destinaiton_name',
|
||||
'src' => 'relation_source_name',
|
||||
|
|
|
|||
|
|
@ -0,0 +1,39 @@
|
|||
# Queries
|
||||
|
||||
## Database
|
||||
|
||||
The database query builder provides a uniform way to write default database queries for the following databases:
|
||||
|
||||
* MySQL
|
||||
* PostgreSQL
|
||||
* SQLite
|
||||
* MicrosoftSQL
|
||||
* OracleSQL
|
||||
|
||||
### Query Builder
|
||||
|
||||
The query builder is used for regular CRUD opperations on the database.
|
||||
|
||||
#### Prefix
|
||||
|
||||
#### Select, Insert, Update, Delete
|
||||
|
||||
##### Random
|
||||
|
||||
#### From
|
||||
|
||||
#### Into
|
||||
|
||||
#### Where
|
||||
|
||||
#### Limit
|
||||
|
||||
#### Offset
|
||||
|
||||
#### Order
|
||||
|
||||
#### Join
|
||||
|
||||
### Schema Builder
|
||||
|
||||
The schema builder is used for schema related operations such as `DROP`, `CREATE` etc.
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
# Localization
|
||||
|
||||
Most of the localization is stored inside the localization object which is part of every request and response as well as the account model.
|
||||
|
||||
## Language
|
||||
|
||||
Language specific text can be used through the `LocalizationManager`, either by directly calling the `getText()` function of the localization manager
|
||||
|
||||
```
|
||||
$this->l11nManager->getText({LANGUAGE}, {MODULE}, {THEME}, {TEXT})
|
||||
```
|
||||
|
||||
or indirectly by calling the `getText()` in the view context.
|
||||
|
||||
```
|
||||
$this->getText({TEXT})
|
||||
```
|
||||
|
||||
The language that should be used for a response should always be depending on the requested language and therefore never be hard coded.
|
||||
|
||||
The language code of the localization object is the 2 character ISO639 code. The corresponding enums are located in the localization directory and labeled with `ISO639`.
|
||||
|
||||
* ISO639Enum Language name
|
||||
* ISO639x1Enum 2 character language code
|
||||
* ISO639x2Enum 3 character language code
|
||||
|
||||
## Country
|
||||
|
||||
The country code of the localization object is the 2 character ISO3166 code. The corresponding enums are located in the localization directory and labeled with `ISO3166`.
|
||||
|
||||
* ISO3166TwoEnum 2 character country code
|
||||
* ISO3166CharEnum 3 character country code
|
||||
* ISO3166NameEnum country name
|
||||
* ISO3166NumEnum country code
|
||||
|
||||
## Units
|
||||
|
||||
### Currency
|
||||
|
||||
The currency code of the localization object is the 3 character ISO4217 code. The corresponding enums are located in the localization directory and labeled with `ISO4217`.
|
||||
|
||||
* ISO4217CharEnum 3 character currency code
|
||||
* ISO4217DecimalEnum currency decimal places
|
||||
* ISO4217Enum currency name
|
||||
* ISO4217NumEnum currency code
|
||||
* ISO4217SubUnitEnum currency sub unit
|
||||
* ISO4217SymbolEnum currency symbol
|
||||
|
||||
## Formatting
|
||||
|
||||
### Currency
|
||||
|
||||
The currency symbol can be placed either in front or at the end of a value. The `Money` class provides a function called `getCurrency()` which returns a localized representation by specifying the thousands and decimal separator as well as the currency symbol and its position.
|
||||
|
||||
```
|
||||
$money->getcurrency(2, ',', '.', '$', 0);
|
||||
```
|
||||
|
||||
### DateTime
|
||||
|
||||
The date/time is versatile and can have multiple formats. By default the localization object stores 5 different date/time formats depending on the degree of accuracy required.
|
||||
|
||||
* very_short
|
||||
* short
|
||||
* medium
|
||||
* 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.
|
||||
|
||||
In the database only the ISO 8601 format will be used.
|
||||
|
||||
### Numeric
|
||||
|
||||
The numeric formatting is defined by a `thousands` and `decimal` separator and available as separate member variables of the localization object.
|
||||
25
services/money.md
Normal file
25
services/money.md
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
# Money
|
||||
|
||||
Money is a delicate element and must be handled precisely. With the `Money` class a precise representation of float up to the precision of 4 decimal places is supported.
|
||||
|
||||
## Initialization
|
||||
|
||||
The initialization can be done by providing an integer, float or string representation. The following list describes how different scalar types get converted.
|
||||
|
||||
* (int) 12300 = 1.23
|
||||
* (float) 1.23 = 1.23
|
||||
* (string) 1.23 = 1.23
|
||||
|
||||
The max and min money values that can be represented on a 32bit system are `214,748.3647` and `-214,748.3647` which is most of the time not sufficient. On 64bit systems however the max and min values that can be represented ar `922,337,203,685,477.5807` and `-922,337,203,685,477.5807`.
|
||||
|
||||
## Operations
|
||||
|
||||
The `Money` class follows the builder pattern. The provided operations are addition, subtraction, multiplication, division, absolute and power.
|
||||
|
||||
## Example
|
||||
|
||||
```
|
||||
$money = new Money(1234567, ',', '.', '$', 0);
|
||||
$money->add(1.0)->sub(10000)->mult('-1.0')->div(new Money(-1.0));
|
||||
echo $money->getCurrency(); // $123.46
|
||||
```
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
# 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.
|
||||
|
||||
## Parameters
|
||||
|
||||
The raw uri string supports parameters that will be replaced with manual or default values. Parameters are always enclosed by `{}` and have a special prefix such as `#./?@$%`
|
||||
|
||||
```
|
||||
$rawUri = 'http://www.yoururl.com/en/some/{/path}?foo=bar&id={@data}'
|
||||
```
|
||||
|
||||
These placeholders will be filled by values that are defined by the `setQuery()` function.
|
||||
|
||||
```
|
||||
UriFactory::setQuery('/path', 'thing');
|
||||
UriFactory::setQuery('@data', 1);
|
||||
UriFactory::build($rawUri) // http://www.yoururl.com/en/some/thing?foo=bar&id=1
|
||||
```
|
||||
|
||||
It is possible to simply use the current uri and simply append parameters if you only want to change or set additional query parameters.
|
||||
|
||||
```
|
||||
{%}&another={@value}
|
||||
```
|
||||
|
||||
### Default Parameters
|
||||
|
||||
Some default parameters can be used for easier use.
|
||||
|
||||
* /scheme = current scheme (e.g. http)
|
||||
* /host = current host (e.g. www.yoururl.com)
|
||||
* /lang = current language (e.g. en)
|
||||
* ?foo = value of the specified parameter
|
||||
* ? = current query
|
||||
* % = current uri
|
||||
* # = fragment
|
||||
* / = root
|
||||
* :port = port
|
||||
* :user = user
|
||||
* :pass = password
|
||||
|
||||
### Frontend Parameters
|
||||
|
||||
While it's also possible to define parameters at the frontend and make use of the default values certain prefixes have a special meaning.
|
||||
|
||||
* #somid = value of the element with the specified id
|
||||
* .somclass = values of the elements with the specified class
|
||||
|
||||
### Dynamic Parameters
|
||||
|
||||
Sometimes a parameter shouldn't be globally defined but is necessary to parse for a specific uri, in that case it's possible to pass an array or object of parameter definitions to the build function where the key is the parameter key and the value is the parameter value it should replace.
|
||||
|
||||
```
|
||||
jsOMS.Uri.UriFactory.build('yoururl.com/en/some/{/path}?id={@data}', {'@data': 1});
|
||||
```
|
||||
|
||||
The match array/object takes priority over the default parameters which means you can overwrite them for a specific uri.
|
||||
|
|
@ -1,23 +1,17 @@
|
|||
# Installation
|
||||
|
||||
Installing the application as a developer can be achived by following one of the following instructions
|
||||
Installing the application as a developer can be achived by following one of the following instructions.
|
||||
|
||||
## General
|
||||
## Server Requirements
|
||||
|
||||
After installation following one of the instructions make sure you set the appropriate permissions for files and directories:
|
||||
|
||||
* 0700 Log
|
||||
* PHP >= 7.1
|
||||
* PDO PHP Extension
|
||||
* Mbstring PHP Extension
|
||||
|
||||
## 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.
|
||||
|
||||
### Requirements
|
||||
|
||||
1. PHP 7.0
|
||||
2. npm
|
||||
3. xdebug or phpdbg
|
||||
|
||||
### Steps
|
||||
|
||||
1. Go somewhere where you want to install the build script
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user