nicht angemeldet
echo $begrüßung;
Es geht darum eine elegante Art zu finden ein PHP Skript zu "steuern".
Mein Ansatz bisher war:
Steuerung des "Interfaces" in einer zentralen PHP Datei (control.php) mittels Auswertung eines GET-parameter "action".
Damit baust du einen Routing-Mechanismus nach, der eigentlich Aufgabe des Webservers ist. Andererseits ist es aus der PHP-Programmierer-Sicht einfacher, nur eine Datei zu pflegen, die die gleichbleibenden Teile enthält und die wechselnden weiterdelegiert, als viele Dateien, die immer wieder die gleichbleibenden Teile mittels des gleichen Codes einbinden. Dieses doppelte Routing - der Webserver routet in jedem Fall, und dann kommt noch deins dazu - ist vielleicht nicht weiter tragisch, doch auf stark belasteten Seiten kann das ein Einsparpotenzial darstellen. Aber betrachten wir dieses Thema erstmal nicht weiter ...
Der Einfachheit halber benutze ich für Add und Change das gleiche Formular, bei dem ich anhand des isset($_REQUEST['change_form']) entscheide welche action bzw. welche submit buttons angezeigt werden.
(z.B. <form action=control.php?action=change&change_id=1234 method="post"> oder in der Liste per normalen, dementsprechenden generierten Link z.B. <a href="control.php?action=delete_form&delete_id=4321>Delete entry 4321</a>
Du verwendest hier Steuerungsdaten (action) und Nutzdaten (id und beim Eintragen der Formdaten auch noch andere Datenbankfelder) gemischt. Was machst du, wenn du ein Datenbankfeld namens action bedienen musst? Einige Webserver und PHP bieten die Möglichkeit, PATHINFO zu nutzen. Man hängt an das Script weitere Parameter an, die wie zum Pfad zugehörig aussehen: http://example.com/pfad/zum/script.php/pathinfo1/pathinfo2?querystring. ("script.php" kann man noch durch mod_rewrite wegbekommen oder so umschreiben, dass das .php nicht mehr auftaucht.) Diese Pathinfo-Teile findet man unter $_SERVER['PATH_INFO'] wieder. Nun hat man die Steuerungsdaten von den Nutzdaten separiert. Aber das nur nebenbei. (Außerdem sind relative Links zu beachten, da der Browser nun möglicherweise falsch nach Bildern, CSS usw. sucht. Am besten mit absoluten Pfaden einbinden.)
Nun aber zu meinem eigentlichen Problem wo ich dann die Übersicht verliere.
Bei einem serverseitigem Formularcheck z.B. checke ich die Daten, halte sie im Falle eines Fehlers in einer Session, und mache einen header-redirect auf die Kontrolldatei mit entsprechenden requestparametern, gebe eine fehlermeldung aus und gebe das formular mit den vorherigen (session restore) werten wieder aus (und lösche dann die entsprechenden session daten). Dazu muss ich aber noch andere Daten halten, wie z.B. ob ich gerade einen Eintrag hinzufügen will oder editieren etc. ... da habe ich bis jetzt meistens mit hidden fields gearbeitet und dann im formular recht oft abgefragt in welchem status ich mich befinde ... usw.
Wenn ich das richtig verstanden habe, sendest du die Daten zwischen mehreren Scripten hin und her und her und hin und zwischdurch in eine Session. Lass doch die Action solange auf Add stehen, bis der Vorgang komplett erledigt ist. Du rufst Add auf, um das Leerformular anzuzeigen. Du rufst Add auf, wenn der Browser die ersten Eingabedaten sendet. Du rufst Add auf, wenn der Browser die korrigierten Eingabedaten sendet. Und nach dem Eintragen der geprüften Daten leitest du auf List weiter. Fertig.
Add selbst prüft, ob es plausible Daten hat, trägt sie ein und leitet zu List weiter, anderenfalls zeigt es das Formular mit den nicht richtigen Daten an. Change macht eigentlich das gleiche, nur dass es bereits ein ausgefülltes ID-Feld hat und mit Daten aus der DB beginnt.
Add und Change sollen hier nur Aktionen sein, ohne dass dabei festgelegt ist, wie sie aufgerufen werden. Ob sie ein eigenes Script sind oder von einem von PHP ausgeführten Verteilmechanismus angesprochen werden, ist prinzipiell egal.
Ist es sinnvoll so eine zentrale steuerungsdatei zu benutzen (oder gibt es eine elegantere Lösung)?? (ich habe keine einfachere und übersichtlichere Lösung im Kopf)
Einfacher ist das Prinzip "ein Script - eine Aufgabe". Aber das hat, wie ich oben schon ausführte, den Nachteil des mehrfachen gemeinsamen Codes - zumindest ein include zum Einladen dieses Teils braucht es in jedem Aufgabenscript. Den Nachteil kann man sich wegkaufen durch eine zentrale Steuerung. Für einfache Fälle kann sie aus einem switch-Statement bestehen, oder sie kann aus einem ausgewachsenen Routing-Dispatch-Mechanismus bestehen, wie ihn der MVC-Teil (dort speziell der durch das C repräsentierte Teil) des Zend Frameworks anbietet. Siehe Zend_Controller.
[...] da ich am anfang der steuerungs datei einfach immer schaue welche buttons ich gedrückt habe [...]
Ich sehe nur Bedarf für einen Submit-Button. Der gehört zum Add-/Change-Formular. Alles andere kann man mit einfachen Links aus der Auflistung erreichen: action=foo;id=42 oder script.php/foo?id=42 (auch die ID könnte man in PathInfo unterbringen).
Ich weiss das ist alles recht vage und grob erklärt ... Es geht mir persönlich eher darum wie man eine PHP-Applikation elegant aufbauen sollte und was pro-kontra für sessions oder $_Request parameter als programm status-"Halter" sprechen. (Ich habs bis jetzt ja irgendwie mit beidem gemacht und dass verwirrt mich immer mehr) ..
Du brauchst die Session nur als Krücke, weil du den Client noch einen Roundtrip in Form eines Location-Headers machen lässt. Vermeide dies und du benötigst die Session nicht mehr (dafür). Beachte immer, dass HTTP ein zustandsloses Protokoll ist. Versuche die Anwendung so zu gestalten, dass du keine Statusinformation irgendwo ablegen musst. Arbeite den Request ab, so wie er kommt und gut ist. Wenn die Daten dafür nicht stimmen, schick sie direkt zur Korrektur zurück.
echo "$verabschiedung $name";