Fusebox framework – Ein Blick ins Innere

Dieser Artikel versucht zu erklären, wie das Fusebox framework unter der Haube funktioniert. Er dient lediglich für mehr Background Wissen zum grossen Ganzen und geht nicht in die tiefen, dunklen Ecken wie Plugins ihre Arbeit verrichten. Die internen Prozesse sollten für Entwickler, die dieses Framework nutzen, nicht wirklich von Interesse sein. Das interessanteste an diesem Artikel für Entwickler, wird der "Request Lifecycle" weiter unten sein.

Wie auch in den vergangenen Versionen von Fusebox, haben die Core files eine einzelne PHP Seite, die als Eingangspunkt für alle Anfragen verantwortlich ist und in eurer index.php included werden sollte, typischer Weise:

include("/fusebox5/fusebox5.php");

Diese Datei erstellt der Reihenfolge nach die myFusebox Struktur und dann, wenn notwendig, die application.fusebox Struktur (oder, eher korrekt, die application[FUSEBOX_APPLICATION_KEY] Struktur). Dann wird das angeforderte fuseaction kompiliert – was oder was nicht dazu führt, dass circuits neu geladen werden und das oder das nicht dazu führt, dass eine geparste Datei generiert wird, abhängig vom execution mode des frameworks.

Die nächsten zwei Abschnitte erklären den "Request Lifecycle" etwas genauer und schauen in den Kern des frameworks um zu erklären wie alles funktioniert.

Der "Request Lifecycle"

Dieser Abschnitt erklärt detailiert die involvierten Schritte beim Abarbeiten einer Anfrage innerhalb des Fusebox frameworks, und ebenso wie ein fuseaction selbst abgearbeitet wird.

Ausführen eines Requests (Anfrage)

Für jede Anfrage, ausgeführt durch die fusebox5.php, werden die folgenden Schritte durchlaufen:

Erstellen des myFusebox Objekts

  1. Wenn dies die erste Anfrage der Anwendung ist oder die Anwendung neu geladen werden muss ("development-full-load" Modus oder der Benutzer verwendet "fusebox.load=true") dann:

Erstelle das application.fusebox Objekt wenn erforderlich (bzw. application[FUSEBOX_APPLICATION_KEY])

  1. Include/Einlesen und Ausführen von fusebox.appinit.php wenn Datei existiert
  2. Include und Ausführen von fusebox.init.php wenn Datei existiert
  3. Erstellen der "parsed/*" Datei wenn erforderlich (entweder sie existiert nicht oder wir sind im "production" Modus), durch Aufruf von compileRequest() aus dem Fusebox application Objekt.

Aufruf der "parsed/*" Datei:

  1. Wenn dies die erste Anfrage der Anwendung ist oder die Anwendung aktualiesiert wurde (siehe oben), ausführen des <appinit> global fuseaction wenn es deklariert wurde. Beachte, es werden in diesem Schritt keine Plugins ausgeführt.  Except that no plugins execute, the specified fuseaction behaves per Executing a fuseaction below.
  2. Ausführen aller preProcess Plugins die deklariert wurden
  3. Ausführen von <preprocess> global fuseaction, wenn deklariert. Die angegebenen fuseactions werden von oben nach unten ausgeführt.
  4. Ausführen der angegebenen fuseactions, von oben nach unten
  5. Ausführen von <postprocess> global fuseaction, wenn deklariert. Die angegebenen fuseactions werden von oben nach unten ausgeführt.
  6. Ausführen aller postProcess Plugins die deklariert wurden

Wenn irgendwelche Ausnahmen (Exceptions) auftraten:

  1. Ausführen der deklarierten processError Plugins

Wenn irgendwelche fusebox.* Fehler (Exceptions) immer noch unbehandelt vorhanden sind:

  1. Ausführen der zugehörigen "errortemplates/" Datei

Ausführen eines fuseaction

Immer wenn ein fuseaction ausgeführt wird, entweder das angefragte Top-Level fuseaction oder via der <do> oder <fuseaction> Verben, werden die folgenden Schritte durchlaufen:

  1. Ausführen der preFuseaction Plugins, die deklariert wurden
  2. Wenn ein prefuseaction für das angegebene circuit existiert, wird dieses ausgeführt

Ausführen des fuseaction:

  1. Jedes der deklarierten Verben im fuseaction wird ausgeführt. Jedes <do> Verb mit dessen spezifischen fuseaction durchläuft den gleichen "Ausführen eines fuseaction" Prozess, rekursiv.

Wenn ein postfuseaction für das angegebene circuit existiert, führe es aus

  1. Ausführen jedes postFuseaction Plugins, das deklariert wurde

Wenn irgendwelche Ausnahmen (Exceptions) auftraten:

  1. Ausführen der fuseactionException Plugins, die deklariert wurden

Wie das Framework funktioniert

Fusebox 5 verwendet Komponenten die verschiedene Teile der Fusebox Anwendung darstellen: verbs, fuseactions, circuits, plugins, classes und natürlich die Anwendung selbst. Die Daten aus den XML Dateien werden verwendet, um diese einzelnen Komponenten zu initialisieren und dann werden die "parsed/" Dateien durch den Aufruf der compile() Methode für diese Komponenten generiert. Jede Komponente weiss, wie sie sich selbst "kompiliert", wie sie PHP code, basierend auf den Daten mit denen sie initialisiert wurde, erstellt. Abgesehen von den <do> und <fuseaction> Verben, welche direkt im framework abgehandelt werden, sind alle anderen eingebauten Verben als ein Teil des individuellen Lexikons (custom lexicon) implementiert (mit "speziellen" Namen). Ein normales Verb wird einfach durch den Include der Implementierungsdatei "kompiliert", und verwendet PHP Code der Methoden wie fb_appendLine() verwendet um eine "parsed/" Datei zu schreiben.

Hier ist ein Überblick der Komponenten, die den Kern bilden:

  • fuseboxAction – dies stellt ein fuseaction dar: Kompilieren eines fuseaction kompiliert lediglich seine Kindelemente (die Verben innerhalb des fuseaction). Zusätzlich hat ein fuseaction Zugriff, Richtlinien und individuelle Attribute ("access", "permission" und eigene).
  • fuseboxApplication – dies stellt eine Anwendung/application dar (und war die normale application.fusebox Struktur in Fusebox 4.1). Ein application weiss, wie eine Anfrage kompiliert wird (z.B. das angefragte fuseaction) genauso wie ein willkürliches fuseaction (z.B. anycircuit.anyaction). Ein application hat ausserdem noch individuelle Attribute.
  • fuseboxCircuit – dies stellt ein circuit dar. Ein circuit weiss, wie ein fuseaction innerhalb dieses circuit kompiliert wird und hat weitere eigene Attribute.
  • fuseboxClassDefinition – dies stellt eine Klasses Deklaration dar. Klassen Deklarationen können eigene Attribute haben.
  • fuseboxDoFuseaction – dies stellt ein typisches <do> Verb und das <fuseaction> Verb dar (für globale fuseaction). Kompilieren eines <do> (oder <fuseaction>) Verbs , kompiliert gleichzeitig die preFuseaction, postFuseaction und fuseactionException Plugins.
  • fuseboxFactory – Diese Komponente erstellt alle Verben Objekte. Es weiss, wie ein <do> / <fuseaction> Objekt erstellt wird, oder ein Lexikon Objekt für alle anderen Verben.
  • fuseboxLexiconCompiler – stellt den dynamischen Zusammenhang her, um Verben zu kompilieren, beinhaltet die fb_* Funktionen die es erlauben "parsed/" Dateien zu schreiben.
  • fuseboxPlugin – dies stellt eine Plugin Deklaration dar und weiss, wie ein Plugin kompiliert wird
  • fuseboxVerb – dies stellt ein Verb aus jedem custom lexicon dar (inklusive des Fusebox eigenen lexicon). Verben werden im dynamsichen Zusammenhang des fuseboxLexiconCompiler Objekts kompiliert.
  • fuseboxWriter – dies handhabt die Erstellung der "parsed/" Dateien
  • myFusebox – dies ist die Daten-Struktur je Anfrage (und war die normale Struktur in Fusebox 4.1).


Quellen:

Orginal (englisch) dieses Artikels: Fusebox Inside the Fusebox framework
Offizielle Fusebox Website: fusebox.org

Anmerkung:
Dieser Artikel ist eine reine Übersetzung des englischen Orginals – leider auch sehr schlecht von mir übersetzt, daher nehm ich gern Korrekturen an. 😉
Für viele englische Begriffe in der Programmierwelt gibt es halt kaum vergleichbare deutsche Übersetzungen, die es besser oder zumindest genauso erklären könnten.

Copyrights:
Orginal (en) von Josh Carrico
Creative Commons License