deavmi/eventy
deavmi
/
eventy
mirror of https://github.com/deavmi/eventy.git
1
0
Fork 0
Code Issues Releases Activity

Updated to use new API

This commit is contained in:
Tristan B. Velloza Kildaire 2022-11-28 18:45:33 +02:00
parent c245e13f90
commit c0455e4011
1 changed files with 28 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
docs/quick_start.md
View File

@ -3,45 +3,44 @@
### The _engine_ ### The _engine_
The first thing every Eventy-based application will need is an instance of the `Engine`. The first thing every Eventy-based application will need is an instance of the `Engine`.
This provides the user with the basic event-loop functionality that eventy provides. It's This provides the user with a single object instance of the [`Engine` class]() by which
the core of the whole framework that exists to have event-triggers ingested into its the user can register _event types_, _signal handlers_ for said events and the ability
_queues_, checking those _queues_ and one by one dispatching each _signal handler_ that to trigger or _push_ events into the engine.
is associated with each queue on each item in the queue.
The simplest way to get a new _engine_ up and running is as follow: The simplest way to get a new _engine_ up and running is as follow:
```d ```d
Engine engine = new Engine(); Engine engine = new Engine();
engine.start();
``` ```
This will create a new engine initializing all of its internals and then start it as well. This will create a new engine initializing all of its internals such that it is ready for
use.
### Queues ### Event types
_Queues_ are as they sound, a list containing items. Each queue has a unique ID which we _Event types_ are effectively just numbers. The use of these is to be able to connect events
can choose. The items of each queue will be the _events_ that are pushed into the _engine_. pushed into the engine with their respective signal handlers (which are registered to handle
An _event_ has an ID associated with it which tells the _engine_ which queue it must be one or more event types).
added to!
Let's create two queues, with IDs `1` and `2`: Let's create two event types, with IDs `1` and `2`:
```d ```d
engine.addQueue(1); engine.addEventType(new EventType(1));
engine.addQueue(2); engine.addEventType(new EventType(2));
``` ```
This will tell the engine to create two new queues with tags `1` and `2` respectively. This will tell the engine to create two new event types with tags `1` and `2` respectively.
### Event handlers ### Signal handlers
We're almost done. So far we have created a new _engine_ for handling our queues and We're almost done. So far we have created a new _engine_ for handling our event tyoes and
the triggering of events. What is missing is something to _handle those queues_ when the triggering of events. What is missing is something to _handle those event types_ when
they have something added to them, we call this an _"event handler"_ in computer science an event of one of those types is pushed into the engine. Such handlers are referred to as
but this is Eventy, and in Eventy this is known as a `Signal`. _signal handlers_ and in Eventy these are instances of the [`Signal` class]().
We're going to create a signal that can handle both the queues and perform the same task We're going to create a signal that can handle both of the event types `1` and `2` that we
for both of them. We do this by creating a class that inherits from the `Signal` base type: registered earlier on. We can do this by creating a class that inherits from the `Signal`
base class:
```d ```d
class SignalHandler1 : Signal class SignalHandler1 : Signal
@ -54,15 +53,15 @@ class SignalHandler1 : Signal
public override void handler(Event e) public override void handler(Event e)
{ {
import std.stdio; import std.stdio;
writeln("Running event", e.id); writeln("Running event", e.getID());
} }
} }
``` ```
We need to tell the `Signal` class two things: We need to tell the `Signal` class two things:
1. What _queue IDs_ it will handle 1. What _event typess_ it will handle
2. What to _run_ for said queues 2. What to _run_ for said event types
--- ---
@ -83,7 +82,7 @@ two IDs, namely `1` and `2`.
As for _what to run_, that is specified by overriding the `void handler(Event)` method As for _what to run_, that is specified by overriding the `void handler(Event)` method
in the `Signal` class. In our case we make it write to the console the ID of the event in the `Signal` class. In our case we make it write to the console the ID of the event
(which would end up either being `1` or `2` seeing as this handler is only registered (which would end up either being `1` or `2` seeing as this handler is only registered
for those queue IDs). for those event types).
```d ```d
import std.stdio; import std.stdio;
@ -111,8 +110,6 @@ engine.push(eTest);
eTest = new Event(2); eTest = new Event(2);
engine.push(eTest); engine.push(eTest);
``` ```
You will then see something like this: You will then see something like this:
@ -129,6 +126,6 @@ Running event1
Running event2 Running event2
``` ```
The reason is it depends on which process gets shceduled by the Linux kernel first, this Despite us pushing the events into the engine in the order of `1` and _then_ `2`, the
is because new threads (special types of processes) are spanwed on the dispatch of each scheduling of such threads is up to the Linux kernel and hence one could be run before
event. the other.