nicht angemeldet
wow .. erstmal danke für die unglaublich ausführliche antwort .. ich hätte nicht gedacht, dass man es wirklich versteht (so wie ich es
geschrieben hab)
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.
Ich verstehe nicht ganz den "Routing-Mechanismus" .. Meinst du als Routing das weiterleiten mittels header()?
(Muss ich nicht automatisch weiterleiten, wenn ich z.B. die Daten eingetragen hab und dann wieder zur Ausgabe will ? oder wenn ich die Daten checke und dann wieder auf das selbe Script weiterleite?
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.)
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.
ok, das hört sich natürlich sinnvoll an .. jetzt habe ich aber das Problem, dass ich z.B. um in ein bestimmtes Feld Daten einzutragen ein anderes Such-Formular aufrufen muss ... von dem ich, nach einer Suche und der Auswahl, wieder zurück in mein Add-Formular muss mit den vorher eingetragenen Daten... Dabei muss ich ja die vorherigen Daten halten und da habe ich eigentlich nur die Session als Möglichkeit gesehen. (ok, abgesehen von unglaublich vielen hidden-fields)
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.
(wenn du hier von einem "eigenen script" redest, bedeutet das z.B. ein include der entsprechenden Skriptdatei, oder?, ein Verteilmechanismus würde ja sowieso benötigt werden um die entsprechende Skriptadatei herauszufinden, oder?
[...] 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).
Stimmt natürlich, wobei noch solche Sachen wie einen Back-Button natürlich ganz hilfreich sein können.
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).
Das kommt eigentlich nur vor wenn ich noch in unterfromulare gehen muss, und die alten Daten halten muss.
Es ist für mich nur schwierig ein Projekt jeweils konzeptionell anzufangen, und da komm ich einfach immer wieder auf die action festlegung durch request-parameter und die verteilung durch ein switch innerhalb einer zentralen datei die jeweils weiterleitet. Ist irgendwie recht übersichtlich und einfach etwas hinzuzufügen.
Habe ich dich richtig verstanden:
Durch direkte Scripteinbindunge würde ich jeweils bei auflistungen mit links und entsprechenden scriptdatien aufrufen, bzw. bei formularen das entsprechende Skript als action eintragen. Eine zentrale Datei würde lediglich den Einstieg bzw. die Ausgabe nach Erfüllung bestimmter Aufgaben bedeuten .. alles andere geht durch direkten scriptaufruf.
Auf jeden Fall Vielen Dank für die ausführliche Antwort.
gruss
caya