Merge pull request #5 from Orange-Management/develop

Update

services/events.md

@@ -0,0 +1,47 @@
+# Events
+
+Events are available in the frontend and the backend. Both implementations provide the same functionality and are implemented in a similar way.
+
+## Creating Events
+
+Every event requires a unique trigger key as well as a `\Closure` which should be called once the event is triggered.
+
+```
+$this->eventManager->attach('eventId', function() { echo 'Hello World'; });
+```
+
+If a event should only be able to be triggered once another boolean parameter has to be edded to the `attach()` function call. 
+
+```
+$this->eventManager->attach('eventId', function() { echo 'Hello World'; }, true);
+```
+
+Now the event will be removed from the event manager once executed.
+
+## Triggering Events
+
+An event can be triggered by calling the `trigger()` function.
+
+```
+$this->eventManager->trigger('eventId');
+```
+
+## Multi Condition Events
+
+In some cases it is required that multiple conditions are met before an event is supposed to be triggered. This can be achived by registering these conditions through the `addGroup()` function.
+
+```
+$this->eventManager->addGroup('eventId', 'conditionName');
+$this->eventManager->addGroup('eventId', 'conditionName2');
+```
+
+Now the event will only be triggered once every registered condition was triggered.
+
+```
+$this->eventManager->trigger('eventId', 'conditionName'); // No output
+$this->eventManager->trigger('eventId', 'conditionName2'); // Hello World
+$this->eventManager->trigger('eventId'); // Hello World
+$this->eventManager->trigger('eventId', 'conditionName'); // Hello World
+```
+
+The order in which these conditions are triggered doesn't mapper. A multi condition event SHOULD be atteched with the optional boolean parameter `true`. These events can only be executed once and will be removed afterwards. In case the optional boolean parameter was not set to `true` the event will remain in the event manager and will be triggered whenever `trigger('eventId')` is called.

services/filesystem.md

@@ -0,0 +1,28 @@
+# Filesystem
+
+The file system provides a simple way to handle operations on the file system. Supported environments are `local`, `ftp`, `git` as well as `aws`. The functionality is for all environments the same.
+
+## Functions
+
+* `exists()`
+* `delete()`
+* `create()`
+* `put()`
+* `get()`
+* `size()`
+* `createdAt()`
+* `modifiedAt()`
+* `move()`
+* `copy()`
+* `list()`
+* `directories()`
+* `files()`
+
+## Custom Implementations
+
+Custom implementations can be created by implementing the FileSystemInterface. These implementations must get registered in the file system and can be used afterwards as the pre-defined implementations.
+
+```
+FileSystem::register('custom1', '\implementation\namespace');
+FileSystem::env('custom1')->list();
+```

services/logging.md

@@ -0,0 +1,43 @@
+# Logging
+
+The core provides two different logging outputs, one is a file output for low level logging such as exceptions, warnings and errors as well as a database logging for activity logging and higher level problems.
+
+Both logging implementations provide the following logging functions for the different logging levels.
+
+* `emergency()`
+* `alert()`
+* `critical()`
+* `error()`
+* `notice()`
+* `info()`
+* `debug()`
+* `console()`
+* `log()`
+
+All functions take at least two parameters where one is the message and the other one is the optional context that should be injected into the message. 
+
+```
+$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.
+
+```
+$log = FileLogger::getInstance('logging/path', false);
+```
+
+Once initialized these two parameters are no longer required. The file logger will create a log file in the provided directory in the format `{Y-m-d}.log`.
+
+## Database Logging
+
+The database logging is recommended for activity logs and abstract high level issues that are not related to the application itself. The database logging is part of the monitoring module which is a core module and should be always installed.
+
+## Client Side Logging
+
+On the client side a logger is also implemented providing the same functions as described above. The only difference is that this logger can remote log messages. Logging messages will get forwarded to the server which will log these messages with the file logger.
+
+```
+let log = jsOMS.Log.Logger.getInstance(true, false, true);
+```