nicht angemeldet
echo $begrüßung;
» Die Formulareingaben sind eigentlich weniger interessant für ihn. Die
Also werde ich dem Formular per action="" die Informationen für die weitere Verarbeitung geben und der FrontCrontroller kann sie per URL weiterverarbeiten.
Ja. So ein FrontController ist nur dann sinnvoll, wenn alle Requests auf ihn geleitet werden und er sie dann verteilt. Welche Aktion ausgeführt werden soll übergibt man am besten im Pfad-Teil der URL. Man hat dann nämlich noch den Querystring und die POST-Daten zur Übertragung von anwendungsspezifischen Daten. Im Pfadteil stehen auch solche Daten, die für das Ergebnis bedeutend sind. Die wertet der FrontController nicht selbst aus, extrahiert sie aber und übergibt sie der Action als Parameter. In Zeile drei des nachfolgenden Beispiels ist die 5 so ein Kandidat.
/board/categories
/board/categogies?sort=name;dir=desc
/board/category/5 gegebenenfalls zuzüglich POST-Daten mit dem Formularinhalt um die Kategorie Nummer 5 zu ändern
Die erste Zeile liefert eine Auflistung aller Kategorien. Die zweite ebenfalls, aber absteigend sortiert nach Namen. Die Sortierinformation übergebe ich deshalb als Querystring, weil der Inhalt der gleiche ist wie bei /board/categories, nur die Anordnung ist eine andere. Man könnte die URL auch als /board/categories/name/desc schreiben, aber für mein Verständnis sieht das eher nach einer signifikant anderen Ressource aus als bei der Variante mit den angehängten Query-Parametern. (Ich las auch, dass die Suchmaschinen (oder die eine zumindest) die Query-String-Variante weniger wichten und damit nicht als Duplicate Content ansehen. Ob's stimmt? Weiß ich nicht. Ich bin keine Suchmaschine und SEO interessiert mich nicht. Es klang jedenfalls plausibel.)
Die dritte Zeile mit GET aufgerufen gibt die Detaildaten von Kategorie Nummer 5 als Formular aus. Als POST aufgerufen zeigt die unveränderte URL an, dass man immer noch mit Nummer 5 hantiert, kann aber nun noch POST-Daten mitliefern. Alternativ kann man auch das Formular an /board/category/edit senden und die ID aus den POST-Daten entnehmen. Oder ... oder ... oder ... Der Kreativität sind da keine Grenzen gesetzt. Auch wenn man ein "fremdes" Framework verwendet, kann und muss man noch genügend eigene Ideen einbringen, so dass trotzdem am Ende auf etwas selbst Geschaffenes zurückblicken kann.
Warum heißt es denn jetzt Action? Der Unterschied zwischen Funktion und Methode ist mir bewusst aber jetzt kommt noch Action dazu. Wo ist denn jetzt der Unterschied zwischen Action und Methode? Nennt man eine Methode Action wenn sie innerhalb eine MVC-Patterns agiert?
Ein Pattern ist erst einmal nur, wie der Name schon sagt, ein Muster, eine Lösungsidee. Man muss so ein Muster nicht unbedingt mit OOP in eine konkrete Form bringen. Ein Pattern beschreibt nur den allgemeinen Aufbau ohne auf konkrete Implementierungsdetails einzugehen. Das sieht man auch an den Begrifflichkeiten. Ein Controller aus dem MVC-Pattern hat eine oder mehrere Actions, je eine für eine bestimmte (Teil-)Aufgabe. Er gruppiert, wenn man so will, Actions zu einem bestimmten Thema. Gießt man so einen ActionController in konkreten Code, noch dazu OOP-Code, so bietet es sich an, den Controller als Klasse und die Actions als Methoden zu implementieren. (Wie immer, kann man auch das MVC-Pattern auf andere Weise implementieren. Unter Python beispielsweise muss man nicht unbedingt eine Klasse anlegen. Jede Code-Datei wird als ein Modul behandelt. Legt man die Actions in einer Code-Datei als Funktionen an, so sind diese schon durch das Modul gruppiert, das Modul ist hier also der Controller. - Ob das eine gute Idee ist, sei mal dahingestellt, es ist jedenfalls eine mögliche.)
Wenn man es genau nimmt, ist bei allgemeinen Beschreibungen des MVC-Patterns immer/meist nur vom Controller, nicht aber von Actions die Rede. Es hat sich jedoch eingebürgert, die Aufgaben eines Controllers in Actions aufzuteilen, was der Übersichtlichkeit und Wartbarkeit dienlich ist.
Du hast geschrieben das der FrontController die Information das ein Request(POST oder GET) entgegennimmt und dementsprechend die passende Klasse instanziert.
Das sehe ich auch so.
Dann aber hast du gerade geschrieben das der FrontController auch die passende Action/Methode aufruft.
Ich nehme mal an du meinst eine Methode die die restlichen Daten des Requests entgegennimmt und dann zwischen Model und View hin und herschiebt oder?
Mit der Instantiierung einer Klasse ist es ja noch nicht getan, denn außer dem Konstruktor ist ja noch nichts ausgeführt worden. Der Konstruktor hat aber nur initialisierende Aufgaben und soll nicht gleicht die ganze Arbeit erledigen. Zumal wir uns ja entschieden haben, zwecks Übersichtlichkeit die Aufgaben eines Controllers in Actions zu gliedern. Wenn der Konstruktor alles erledigte, bräuchte man für jede Action eine eigene Klasse ... und könnte gleich "herkömmliche" Funktionen nehmen.
Könnte man sich diese Methode dann nicht sparen und in den Konstruktor packen? Sie wird doch eh jedes mal benötigt. Weil ohne Daten - macht das Ding nichts. Selbst ohne Daten wir dann reagiert weil er keine Daten hat.
Schau dir nochmal den BoardController an, so wie ich ihn bereits skizziert habe. Er hat ja viele Aufgaben. Er muss nicht nur auf verschiedene Weisen mit den Beiträgen umgehen sondern auch Kategorien anzeigen und eventuell bearbeiten können. All diese Teilaufgaben separiert man besser als sie in einem großen Codehaufen unterzubringen.
Ich wüsste sonst auch nichts was in den Konstruktor reinpassen könnte, ausser sich Variablen zurechtzuweisen.
Lass ihn einfach leer oder weg, wenn dir im Moment dafür keine Verwendung einfällt.
echo "$verabschiedung $name";