WilliL wrote:Andererseits sind "Endlosschleifen" (Repeat ... Until (TRUE)) ein normales Instrument in der Programmierung um valide Daten zu erzwingen.
Dieser Äpfel mit Birnen Vergleich ist nicht sehr gelungen. Das eine ist ein Kontrollfluß (welches auch durch Dateinamen erkennbar sein sollte), bei dem man auch erkennt, in welchem Bearbeitungsstadium eine Applikation ist, das andere ist ein ganz normales Instrumentarium der strukturierten Programmierung.
WilliL wrote:Die Akzeptanz bei einem User ist gering, wenn er immer von vorne anfangen muss, weil ersich einmal vertippt hat
Verstehe ich leider nicht?!
WilliL wrote:Vermutlich ist die Betrachtungsweise davon abhängig, über welchem Bereich man an den "Serverbetrieb" gekommen ist.
Verstehe ich ebenso leider nicht.
WilliL wrote:Das Ziel hier ist ja "fest verdrahteten Namen" zu nutzen, nur dass diese bei mir in der Datei "konstanten.inc.php" ausgelagert sind, bzw dort generiert werden. (Ich halte XSS für gefährlicher als häufig dargestellt wird.)
Was sicherlich nicht schlecht ist.
WilliL wrote:Hier geht es um ein Formular (Selfservice-Adressen), bei dem ich beim Aufruf die Daten aus einer DB hole und sie per Voreinstellung in das Fomular eintrage. Der User kann sie dann anpassen/korrigieren. Bei Fehlern (z.B. nicht akzeptierte Zeichen) wird der Datensatz dann mit optischem Hinweis mit den eingegebenen Zeichen angezeigt - es ist halt von der Funktionalität immer der gleiche Aufruf bis die Daten akzeptiert werden oder der User abbricht.
Hier fällt mir keine alternative Lösung mit 2 Scripts ein. Spätestens beim 2. Script hätte ich die ursprüngliche Herausforderung.
Gibt es hier einen alternativen Lösungsangang?
Allerdings. Damit schlägst Du gleich die nächste Fliege mit der gleichen Klappe, denn anscheinend hast Du eine "monolithische" Programmstruktur (sprich: es gibt nur ein Riesenscript mit allem drin).
Trenne es auf nach Funktion (beispielsweise "get.php", "put.php", "update.php", "error.php" usw.), wie es Dir im Kontrollfluss sinnvoll erscheint. Und dann trennst Du außerdem HTML und PHP weitestgehend und modularisierst (falls möglich) auch noch die HTML Komponenenten. Dann wird es ggf. ein Modul "formular.html.php" o.ä. geben, da steht beispielsweise nur das Formular drin, die Werte sind globale Variablen und diese werden vom Steuerscript bestückt (kommen je nach dem entweder direkt aus einer Datenbank, oder eben aus einem User-Post und anschließender Validierung) entsprechend wird auch das action-Tag variabel gesetzt und dieses Formular (resp. möglicherweise noch das HTML Rahmentemplate) wird via include() ganz am Ende der PHP Verarbeitung inkludiert. So ist es dann auch sehr einfach möglich, dem Anwender nur eine Meldung zu senden "Datensatz wurde erfolgreich geändert", ohne erneut Formular anzuzeigen. Das Formular (oder ggf. eben eine komplette HTML Seite inkl. Formular - das mußt Du selbst herausfinden, wie die Struktur am besten aufzuteilen ist) wird eben nur inkludiert, wenn die Daten vom Anwender bearbeitet werden sollen.
In diesem Formular kannst Du dann beispielsweise auch den Eingabefeldern dynamisch verschiedene class-Werte (CSS) zuordnen. Wenn beispielsweise ein Datum falsch formatiert ist, bekommt das Datumseingabefeld die class "error", und diese Klasse umrandet das Eingabefeld rot und stellt den Inhalt fett dar (nur als Beispiel). Und Felder, deren Inhalt korrekt ist, bekommen als class den Wert "standard" (oder ggf. sogar vom Inhaltstyp anhängig, also "datum" oder so, falls Du solche Felder anders darstellen willst).
P.S.: Insgesamt kommt mir die Datenverarbeitung sehr unkomplett vor. Normal ist doch eigentlich diese Funktionalität:
1) Neuanlage
2) Anzeige ("browse") vorhandenere Datensätze (mit Suchfunktion resp. "Filterfunktion", beispielsweise nach bestimmten Orten suchen)
2a) Auswahl eines vorhandenen Datensatzes
3) Ändern eines vorhandenen Datensatzes
3a) (sowie 1a) folgt Validierung der eingegeben Daten
4) Zurückschreiben des neuen/geänderten und validierten Datensatzes
5) Auswahl und Löschen eines vorhandenen Datensatzes
5a) ggf. mit Bestätigung ("confirm") des Löschvorgangs
Das sind (grob) die einzelnen Transaktionsschritte, die für die Pflege einer Datenbank notwendig sind. Davon sehe ich oben nur 3 und 3a und 4.