nicht angemeldet
Moin,
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?
In Deiner Klasse (Code). In der Verwaltung (Konfiguration). Das sind zwei unterschiedliche Dinge und klar voneinander getrennt.
Das war glaub ich ein bisschen unglücklich ausgedrückt. Was ich meinte war: 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.
Ganze einfach in der Webserverkonfig:
ErrorDocument 404 => ResponseHandler (index.php)
Alle Requestse => ResponseHandler (index.php)
Der Trick, damit Beides funktioniert: Der ResponseHandler (index.php) steht NICHT in der Verwaltung.
Was meinst du mit "Verwaltung"?
Das ist die Konfiguration, siehe weiter oben: Eine Tabelle mit ALLEN URLs, welche Deine Website beinhaltet.
Das mit den Templates hab ich mir auch schon so vorgestellt, wie du es beschreibst. Aber ist "submit" hier nicht der falsche Begriff? Ich würd es eher als Request bezeichnen, wobei Ajax ja auch ein Request ist... 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?
Es muss dafür gesorgt sein, dass der Controler unterscheiden kann, ob ein Submit oder ein Ajaxrequest vorliegt. Das kann über einen speziellen Header erfolgen oder anhand eines Parameters.
Insgesamt, merke ich jetzt, ist das Thema echt komplex. Man könnte jetzt seine alten nicht-OOP-Scripte einfach so hinbiegen, aber dann hat man das OOP ja nur um des OOP Willen und nutzt die Vorteile gar nicht
Siehs mal so: Deine Verwaltung, die Konfiguration ist eine Sammlung von Objekten. Das ist die Grundlage dafür, OOP zur dynamischen Erstellung von Webcontent nutzen zu können.
Hotti