Naja. Eher zur Vereinfachung. Denn man muss sowieso für jedes erwartete Item prüfen, ob der Schlüssel (Name) vorhanden und das Item mit passenden Daten befüllt wurde.
Das ist mir neu. Oftmals sind POST-Werte doch aber auch leer.
Da aber viele Requests von Angreifen oder Testern mit Daten gefüllt werden, die mit dem als Referer vermuteten Formular nichts zu schaffen haben, kann man sich nach der Prüfung auf den Key und Wert des Submit-Buttons in Negativ-Fall den ganzen Rest sparen.
Wieso den Key und den Wert? Ich dachte, ich gebe dem Submit-Button einfach ein Name-Attribut und der Wert dieses Attributs wird bei der POST-Anfrage immer mitgeschickt. Also z.B.
<button name="sign-in">einloggen</button>
Und dann zu Beginn des Scripts, das durch die POST-Anfrage eingeleitet werden soll, einfach mit isset()
prüfen, ob $_POST['sign-up']
vorliegt.
Vollständig sieht Dein Beispiel grob so aus:
if ( isset( $_POST['sign-up'] ) ) { versuche_daten_zu_verarbeiten(); } else { sende_formular(); }
Mit sende_formular() meinst du, dass man zurück auf die Seite, auf der sich das Formular befindet, weitergeleitet wird?
Denn gerade bei „Affenformularen“ (das gleiche Skript erzeugt das Formular und verarbeitet die Daten), hat man so eine einfache Möglichkeit, ohne viel Firlefanz die Frage zu entscheiden, ob das Formular gesendet oder mutmaßlich vorhandene andere Daten geprüft oder verarbeitet werden sollen. Das ist regelmäßig der Hauptzweck des von Dir gezeigten Vorgehens.
Danke, das ist gut zu wissen.
Ein weiteter Zweck:
Ein Formular kann mehrere Submitter haben. Dann muss man für die Auswahl der nachfolgenden Aktionen natürlich prüfen welcher davon mit dem Klick, Tastendruck oder Fingertipp „erfreut“ wurde.
Ja, in diesem Fall ist es natürlich ohnehin ein Muss. Mir ging es eher um Formulare, die nur einen Submit-Button haben.