nicht angemeldet
Hi!
Du sprichst von einer "Verwaltung der Seiten", das passt, gute Idee! Geht dann wie folgt weiter: load.php kriegt den Request, ermittelt aus REQUEST_URI den PATH und fragt in der Verwaltung nach, ob es den gibt. Wenn ja, wird ein Response-Object (Instanz Deiner Klasse) erstellt, wenn nein, ein 404 geworfen.
Das ist ja meine Frage 2: Wo geschieht das alles? Innerhalb einer Klasse? Klatsche ich das jetzt einfach als Code in eine .php?
Besser nicht. Damit ignorierst du schon das simple Trennungsmuster nach dem EVA-Prinzip und erzeugst dir eine komplexe Riesenklasse, die sich mehr oder weniger nur mit Fallunterscheidungen zum Ende hin durchschlängelt. Dann hast du von den Vorteilen der OOP nur ganz wenige genutzt und stattdessen irgendwas zwischen "unstrukturierter Ablaufsteuerung" und "strukturierter und funktionsbasierter Steuerung" im OOP-Gewande erstellt.
Im Ja-Zweig gehts dann so weiter: Das Response-Object ruft nun die Methoden auf, welche die Seite erzeugen. Eine weitere Kontrolle prüft, ob Parameter anliegen. Somit können nun alle möglichen Content-Types ausgegeben oder ein Template bestückt und ausgegeben werden.
Alles kein Problem.
Das wird ein Problem, weil das Response/Page-Objekt so etwas wie ein fettes switch oder ein schlankes mit einer Menge spezialisierter Methoden braucht, um die jeweiligen Daten zu ermitteln. Zumindest ist das so, wenn es nur eine Response/Page-Klasse gibt und nicht für jeden unterschiedlichen Request eine eigene.
Die Klasse "page" versucht die angeforderte Seite zu laden (Überprüft ob die Datei existiert). Was tut sie, wenn die Datei nicht existiert? Automatisch die 404-Seite laden? Oder einfach nur false zurückgeben und irgendwo anders (wo?) wird dann ermittelt, dass die 404-Seite im Falle einer nicht gefundenen Seite geladen werden muss und der Klasse gesagt, sie solle jetzt die 404-Seite laden.
Schon der Front-Controller findet heraus, ob er die Anfrage zum Abarbeiten weiterleiten kann oder nicht. Wenn nicht, gibt er die 404er-Antwort direkt zurück. Dazu kann er sich ruhig eines 404er Templates bedienen. Aber Umleiten ist definitiv Mist - schon aus HTTP-Sicht. Eine Umleitung ist Status-Code 30x und die Fehlerseite ist nicht 404 sondern 200. Anderenfalls weiß der Client nicht, ob das eigentliche Ziel nicht vorhanden ist oder das Umleitungsziel. Und bei 200 geht er sowieso von "alles ok" aus.
Ich machs nicht kompliziert, ich hab nur gefragt, weil ich mir nicht sicher war: Lädt die Klasse "page" automatisch eine Fehlerseite, oder wird ihr das von außen gesagt?
Siehe meine Antwort. Meiner Meinung nach solltest du die Aufgaben deutlicher trennen und die Zuständigkeiten der einzelnen Klassen überschaubar klein halten.
Das beantwortet jetzt glaub ich indirekt meine Frage: Es gibt einen Controller, der eben alles "kontrolliert". Der wird einfach am Anfang aufgerufen und macht dann den Rest. Im Hauptscript steht also nichts, außer dem Controlleraufruf, oder?
Ja, aber der macht nicht den Rest, der delegiert den Rest an die jeweiligen Spezialisten weiter.
Aber müsste dieses Überprüfen ob Ajax oder "normaler" Request, nicht eher Teil einer Extra-Klasse "template" sein, die das laden und bestücken der Templates übernimmt?
Bei Frameworks nach dem MVC-Muster gibt es Action-Controller, die für ein bestimmtes Aufgabengebiet zuständig sind. Die einzelnen Requests dieses Aufgabengebiets landen vom Front-Controller und seinen Vasallen (Router) ermittelt bei einer der Action-Methoden des Controllers. Ajax-Requests und herkömmliche Request sind unterschiedlich abzuarbeiten und landen auf eigenen Action-Methoden. Sie können zwar die gleichen Verarbeitungen erledigen / die gleichen Daten holen, das machen sie aber, indem sie sich desselben Models bedienen. Die Antwort ist jedoch spezifisch und wird der einen oder der anderen View zum Formatieren übergeben. Am Ende der Action-Methode ist allerdings in guten Framworks nur bekannt, welche View gewählt wurde und welche Daten übergeben werden sollen, die View aber hat noch nicht gearbeitet. Wenn erst der Front-Controller das Rendern anstößt hat auch noch ein Vor-der-View-Plugin die Chance den Rendering-Prozess zu beeinflussen. Vielleicht ist das in deinem Fall YAGNI, doch wenn dein Framework universal einsetzbar sein soll, sollten auch solche Anwendungsfälle berücksichtigt werden können.
Viel zu lernen... Gibts da evtl. Literaturempfehlungen (Deutsch wäre schön :D)?
Garantiert gibt es Bücher, die ein bestimmtes Framework beschreiben, vielleicht auch allgemeine zum Thema. Und die Muttersprache liest sich im Allgemeinen auch flüssiger. Doch früher oder später wirst du an Englisch nur vorbeikommen, wenn du dir ein anderes Hobby suchst. Also nutze lieber die Gelegenheiten mit der Originaldokumentation auch deine Lesefähigkeiten zu verbessern.
Lo!