Gerade mein Framework widerlegt ja das ganze OOP-Klischee. Nämlich dass OOP eben nicht die Lehre von Äpfeln und Birnen ist sondern eine praktische Angelegenheit. Mein FW implmentiert MVC über eine einstufige Klassenhierarchie. Guck in den Quelltext einer beliebigen Einzelseite, da steht der Name einer Klasse drin und ggf. der Name eines Interfaces. Routing in meinem FW heißt das Binden einer URL an eine Klasse.

Und anstatt das Routing im Code abzubilden benutzt mein FW eine statische Routingtable die gleichzeigig die Konfiguration darstellt. Aus OOP Sicht sind z.B. title und descr einfach nur Eigenschaften die bei jedem Request an die FW-Instanz gebunden werden. Auf all diese Eigenschaften sowie auf die komplette Konfiguration für eine Domäne hat die bei jedem Request erstellte FW Instanz Vollzugriff, weil die Routingtable komplett im Hauptspeicher liegt.

Die Routingtable selbst braucht keine Methoden, ist also ein reines Datenobjekt. Jedoch hat die FW Instanz Methoden um mit der Routingtable und Konfiguration richtig umgehen zu können. Z.B. eine Methode mit Namen eav():



Auch bei RPC wird eine FW Instanz erstellt. Content Management wird damit zum Kinderspiel, weil diese Instanz auch persistente Daten ändern darf. Das eigentliche FW Script hab ich schon lange nicht mehr im Editor gehabt. Für eine neue Anwendung erstelle ich einfach eine neue Subklasse, trage die in der Konfiguration ein, fertig.

Das kann ich sogar auf dem Produktiven Server machen ohne dass es den Regelbetrieb beeinträchtigt. Z.B. an einunddenselben URL /shop.html eine Testdatenbank binden.

PS: Das verlinkte codebeispiel zeigt eine ganze Menge über OOP. browse() ist eine Interface Methode und wird aufgerufen, wenn keine Parameter im Request sind. Über die {STASH} Eigenschaft der FW Instanz werden Defaultwerte gesetzt die in der Anwendung zu sehen sind und dafür später ins Template gerendert werden. Hierzu wirken Instanzen nicht verwandter Klassen zusammen.

Die IF Methode control() wird von der FW Instanz aufgerufen wenn Parameter im Request sind. Die Instanz wird über Aggregation befähigt, Parameter zu parsen und hat hierzu eine Methode param() welche Delegation nutzt.

Je nach Parameter wird über eine Instanz der Scaliger Klasse das Ergebnis berechnet und in {STASH} gesetzt. Bei einer fehlerhaften Eingabe wirft Scaliger eine Exception deren Meldung über eine eigene Methode der FW Instanz in die Antwortseite eingebaut wird.

Das Formular Template befindet sich im __DATA__ Bereich.

Die IF Methoden browse(), control() und ein paar weitere werden von der main-Class geerbt. In dieser Basisklasse ist praktisch alles drin was bei jedem Request gemacht werden muss: Stets ist der Ablauf derselbe bei jedem Request. Verzweigungen gibt es lediglich wenn Parameter im Request sind. Manch andere FW haben Request- und ResponseObjekt getrennt. Bei meinem FW jedoch ist alles zusammen in einem Objekt, der FW Instanz vereinigt, weil es ohnehin unmittelbar zusammenwirkt.

Die FW Instanz verbleibt natürlich nicht im Speicher sondern wird zerstört sobald die Response raus ist und bei jedem neuen Request neu erstellt.
Last edited: 2017-07-17 19:22:41 +0200 (CEST)