nicht angemeldet
Hey dedlfix,
wieder einmal vielen Dank für Deine Antwort. Du entwickelst Dich ja schon fast zu meinem persönlichen "Mentor" :-)
Kurz mal OT: Nicht nur Du, dedlfix, hilfst mir riesig, sondern auch alle anderen, die hier ständig "rumschwirren". All die Namen aufzuzählen würde wohl den Rahmen sprengen, deshalb "DANKE!" an alle die sich hier zurecht angesprochen fühlen.
Ich bin ja hier im Forum noch nicht allzu lange aktiv, obwohl ich den Großteil meiner Kenntnisse über HTML, CSS und JavaScript bei SelfHTML erworben habe. Nur ist die Dokumentation und das Forenarchiv einfach zu gut: Ich hatte keinen Grund, mich anzumelden oder etwas zu schreiben, da eigentlich jede Frage schon einmal behandelt wurde.
So, jetzt aber genug und wieder zum Thema :-)
ich arbeite gerade an einem kleinen PHP-Framework. In erster Linie, weil ich die ganzen Prozesse besser verstehen will und zweitens, weil mir andere Frameworks - wie soll ich sagen - zu "überladen" sind.
Die Frage ist, welcher Funktionsumfang soll's denn sein? Je mehr Wünsche implementiert werden, desto überladener wirkt es. Du fängst mit deinem zwar klein an, aber letztlich sieht es in gewissem Rahmen auch überladen aus, wenn du Funktionalität reinbringst, die du nur für bestimmte Projekte benötigst, für das gerade betrachtete aber nicht.
Hmm... Damit wirst Du wohl rechthaben. Ich wollte mich eigentlich nur auf das ganz Essentielle beschränken, was man für eine Web-Anwendung benötigt. Allerdings mit der Möglichkeit zur Erweiterung. Und wenn ich das weiterspinne, komme ich wahrscheinlich wieder zum zuvor von Dir genannten.
Ich hatte auch schon ein kleines Framework, habe es aber vor ein paar Tagen eingemottet, da ich hierbei nicht konsequent sauber programmiert habe, was ja bekanntlich ab einem bestimmten Punkt Erweiterungen sehr erschwert.
Und dann ist die Frage, ist der Aufwand des Selbsterstellens inklusive der unvermeidlichen Tour durch den Sackgassen enthaltenden Irrgarten immer noch deutlich kleiner, als die Einarbeitung in ein bestehendes Framework?
Das sicherlich nicht! "Selbstgemacht" ist wesentlich aufwendiger als die Einarbeitung in Bestehendes.
Ich nutze, vor allem in dem Institut, in dem ich arbeite, das Zend-Framework. Die Einarbeitung habe ich somit einigermaßen hinter mir. Allerdings war auch genau das der Punkt, warum ich ein eigenes, neues Framework auf die Beine stellen möchte (zusätlich zu dem Punkt nach dem nächsten Zitat): Einiges im Zend-Framework (von dem ich aber - das muss man sagen - viel gelernt und mir vieles abgeschaut habe) ist für mich nicht ganz durchschaubar und nachvollziehbar. Vieles erscheint, dass die Entwickler zeigen wollen, wie "geil" sie doch sind (und das fängt schon bei Kleinigkeiten wie array_push($array, $value) statt $array[] = $value an; auch etwas, dass ich dort gelernt habe und worüber wir uns in einem anderen Thread schon unterhalten haben).
Oder sie treiben OOP "auf die Spitze", in dem der Name einer Datenbank-Tabelle eine eigene Klasse erhält (also nicht gezwungenermaßen, sondern bei dem, was möglich wäre). Da kann ich auch die "bei-OOP-zuviel-Overhead"-Nörgler verstehen, da für mich nach Kosten-Nutzen-Rechnung mein Argument mit der besseren Wartbarkeit - trotz Caching - verschwindend gering ausfällt.
Oder spielen andere Aspekte, wie eigene Weiterbildung und dem Lernen aus Fehlern oder schlicht der Spaß an der Freude eine Rolle?
Definitiv beides. Wie bereits gesagt möchte ich das ganze auch verstehen, was ich da mache. Und Spaß habe ich auch daran.
Nun zu meiner Frage: Gehört das Routing in den Bootstrap-Prozess oder ist es die Aufgabe des Front-Controllers, dies zu übernehmen?
Letzteres. (siehe auch weiter unten)
Der Front-Controller sollte doch eigentlich nur ein "vollständiges", also bereits geroutetes (gibt's dieses Wort eigentlich?) Request-Objekt bekommen und eine Antwort zurückgeben?
Wenn du schon fertig bist mit dem Routen, dann kennst du ja schon den aufzurufenden Action-Controller und hast keine Aufgabe mehr für einen Front-Controller.
So war es bei mir bis jetzt ja auch. Also, dass der Front-Controller das Routing übernahm.
Aber eine Aufgabe hätte der Front-Controller noch immer: Er ist die oberste Controller-Instanz. Nachdem er einen speziellen Controller aufgerufen hat, könnte dieser Controller ja noch einen anderen, speziellen Controller für eine Aufgabe benötigen. Der sollte allerdings nicht direkt, sondern über den Front-Controller aufgerufen werden, damit dieser die Entscheidung treffen kann, ob dies überhaupt möglich ist. Außerdem hatte mein Front-Controller die Aufgabe, die Response zu senden (also Header und anschließend die View).
Aber wohin dann mit dem Routing? In den Bootstrap-Prozess? Auch das ist für mich nicht ganz stimmig. Denn bislang war meine grobe Struktur:
Die Einteilung nach den Pattern ist nicht unbedingt eins zu eins auf Klassen zu übertragen. Es kann durchaus auch sein, dass in (d)einer Implementierung Pattern-Elemente und Klassen nicht aufeinanderfallen - nicht in dem Sinne, dass für ein Element mehrere Klassen benötigt werden sondern, dass Teile der Klassen X und Y für das Patternelement verwendet wurden und die anderen für andere Elemente. Ob das sinnvoll ist? Vermutlich nicht, denn man hat ja nicht umsonst diese Elemente und deren abgegrenzten Aufgabenbereich beschrieben. Also sollten auch deren Grenzen an den Grenzen der Programmierelemente (z.B. Klassen, Namespaces etc.) zu sehen sein.
Das musste ich mir jetzt mehrfach durchlesen, um es zu verstehen. Aber mein Problem ist ja gerade, wo ich die Grenzen ansetzen sollte / muss.
- Anwendung wird aufgerufen: Alle für die Anwendung unabdingbaren "Prozesse" werden initialisiert und gestartet
Das ist das Bootstrapping - Urladen. Da sehe ich eigentlich nur ganz grundlegende Initialisierungsaufgaben. Der Rest ist dann eher schon Front-Controller.
Auch hier liegt mein Problem. Nach meinem jetzigen System hätte ich keine Verwendung für das Bootstrapping:
Das Laden von Konfigurationsdaten und die Initialisierung des Autoloaders finden bei mir beim Aufruf der Anwendung statt.
Beispielsweise die Datenbankverbindung wird bei mir - weil nicht immer zwingend erforderlich - über ein Plugin im Bootstrap-Prozess initialisiert.
- Bootstrapping: Alle optionalen Plugins, Aufgaben, etc. werden geladen und evtl. ausgeführt
Ob das noch Bootstrapping ist?
Das ist die Frage...?! ;-)
- Der Front-Controller übernimmt, delegiert also an spezielle Controller und gibt am Ende die Response aus
Der nimmt den Request entgegen (oder holt ihn sich) und routet ihn zum Ziel. Außerdem kommen weitere globale Aufgaben auf ihn zu, wie Initialisierungen für eine Lokalisierung oder das Resultat des Action-Controllers an das Ausgabemedium zu leiten.
Wenn dem so ist, hast Du zumindest meine spezielle Frage komplett beantwortet. Wenn der Front-Controller all diese Aufgaben, die ich (weil's sich so schön anhört :-)) Plugins nenne, ausführen soll(te), haben die bei mir im Bootstrapping nichts zu suchen. Ebensowenig wie das Routing.
Gruß und nochmal danke, Dennis
Struppi