Server

Um hier eine kleine Übesicht zu geben, schauen wir uns den Aufbau des Projektes aus
der Vogelperspektive top-down an.

Warum Skripte?

Struktur

Zu aller erst: das Projekt ist als Skript geschrieben, welches den Kontrollfluss nach unten abgibt.
Die "oberen" Skripte rufen die unteren Skripte auf, damit diese ihre Aufgaben erfüllen können.
Die erste Anlaufstelle ist hier der Kontrollfluss von dem Index zu den Skripten aus dem Modul Routing.
Vom Modul Routing aus werden alle weiteren Skripte geladen und ausgeführt.
 

Nachteile

Die Implementierung mit Skripten hat jedoch auch Nachteile.
So besteht für die Skripte kein einheitlicher Codestandard.
Ebenfalls wird man mehr dazu verleitet, globale Variablen zu verwenden, was mit dem Zustand der Applikation Unfug treiben kann.

Hinweis: In diesem Projekt werden globalen Variablen verwendet.
Zum einen werden die Konfigurationsvariablen als Konstanten genutzt. Ebenfalls werden die variablen 
$_SESSION, $_POST und $_SERVER verwendet. Diese können und sollen nach und nach ausgetauscht werden.
 

Warum Prozedural?

Lesbarkeit

Die Lesbarkeit des Codes ist wesentlich besser als bei der vorherigen Implementierung.
Durch die Erhöhung der Lesbarkeit ist es einfacher, den Code zu verstehen und zu warten.

Zustand

Anstatt den Zustand per DependencyInjection zu übergeben, wird der Zustand direkt bearbeitet.
Das hat den Vorteil, dass der Zustand nicht mehr übergeben werden muss und somit die Funktionen
einfacher zu schreiben sind. Das kann zu Problemen führen, wenn der Zustand nicht mehr eindeutig ist. 
Bei kleineren Projekten ist es leichter den Zustand zu verfolgen, als bei größeren Projekten.

Hinweis: In diesem Projekt wird der Zustand direkt bearbeitet. Hierzu haben 

die meisten Skripte eine function necessary() welche definiert, wie der Zustand der Applikation

aussehen muss, damit das Skript ausgeführt werden kann. Im Falle eines Fehlers wird eine Exception geworfen.

 

Modularität

Die einzelnen Module beinhalten die Implementierungsdetails. Das bedeutet, dass die einzelnen Module
nicht von den anderen Modulen abhängig sind. Das macht es einfacher, die einzelnen Module zu warten.
z.B bei den Skripten im Ajax Ordner sollte relativ klar sein, was sie machen. Die Dateien im Ordner sind
in der Regel nach dem benannt, was das Skript tut.

Aufbau des Projekts

Wie bereits erwähnt wird der Kontrollfluss von oben nach unten abgegeben.
Ein unteres Modul soll nicht ein oberes Modul inkludieren. 
Der Fluss geht folgendermaßen:

Index -> Routing -> Ajax/Page/Api -> Komponente

Hinweis: Die CRUD Operationen befinden sich im Ajax Ordner und das Datenbank schema ist
als SQL Datei im Ordner database zu finden.

Gui

Aufbau

Die grafische Oberfläche wurde mit Bootstrap und jQuery Standartkomponenten erstellt.
Als weitere Bibliotheken wurden JqueryValidate und toastr verwendet.

Eigenheiten

Die Schaltflächen z.B um einen neuen Nutzer anzulegen, wurden als Bootstrap modal erstellt.
Innerhalb dieser Schaltflächen dient der Modal Body als Formular.
Der Modal taucht auf, wird mit Daten gefüllt und auf klick werden die Daten aus der Form
an das Backend gesendet. 

Stil

Jede Page hat ihre eigene Javascript Datei, die das Verhalten der Page wiederspiegelt.
Ganz oben befindet sich meist die Document.Ready function und darunter onklick Functions,
welche die Funktionen weiter unten lostreten sollen. Dadurch hat man einen guten Überblick
was die Page macht.