Der Martin: $_GET vs. $_POST

Beitrag lesen

Hallo,

»» > [...] Das gilt natürlich auch für Textfelder.
»» Nein.
hey, hey! Nicht einfach verkürzt zitiren und den Sinn verdrehen!

ich habe den Sinn genau so wiedergegeben, wie ich ihn verstanden hatte. Sorry, dann habe ich dich missverstanden. Du hattest noch das Affenformular erwähnt, und so dachte ich, du beschreibst die Situation, dass der User beim ersten Absenden etwas ins Textfeld eingetragen hat, es beim zweiten Absenden aber wieder löscht, und dass das dann leere Textfeld dann nicht mehr übertragen würde. Und das wäre falsch.

Nochmal in extra-lang:
Das gilt auch für Textfelder, dass es unpraktische ist, wenn man nicht weiß, ob das Feld nun zurückgesetzt werden soll, oder ob es einfach "vergessen" wurde, zu übertragen, z.B. weil man im Formular einen Fehler/eine Änderung im Namen geamcht hat, aber das Backend nicht angepasst hat.

Dann sprichst du von der Testphase, nicht vom produktiven Einsatz eines fertig ausgetesteten Formulars und seines Backends. Okay.

»» > Du kannst aber im Backend leicht abfragen, ob das Element benutzt wurde:
»» Was verstehst du hier unter "benutzt"?

Da du die Frage nicht beantwortet hast, mutmaße ich: Mit "benutzt" meinst du, dass ein Wert in dieses Feld eingetragen wurde?

»» Die Prüfung auf strlen()>0 ist m.E. überflüssig. Auch mit einem Leerstring als Parameter ist isset() erfüllt, der Zugriff auf den entsprechenden $_POST- $_GET-Eintrag also ohne Fehler/Notice möglich und erlaubt.
??? Den Satz verstehe ich nicht. Es ging doch gerade darum, festzustellen, welche Felder übertragen wurden und welche davon auch benutzt wurden. Wenn man nun unterschiedliche Formulare als Quelle hat und immer dasselbe Ziel, dann hat diese Abrage durchaus einen Sinn.

Sehe ich nicht so. Wenn das Formular, das abgesendet wurde, ein entsprechendes Textfeld enthält, dann wird es auch übertragen (unabhängig von seinem Inhalt). Also liefert isset($_REQUEST['feldname']) ohne Zweifel die Information: Formular enthält (k)ein Feld namens 'feldname'.
Mit der Abfrage auf strlen() prüfst du aber schon den *Inhalt* des Feldes, obwohl ein Leerstring ja in vielen Fällen auch ein gültiger Wert sein kann. Diese Prüfung sehe ich deswegen an der Stelle als unangebracht.

Das einzige, was hier wohl obsolete ist, die das trim($_POST['element']) vor dem strlen(), da dies von HTTP und PHP selber erledigt wird. Darum habe ich es hier weggelassen.

Daran habe ich jetzt nicht einmal gedacht.

Üblicherweise prüft man das isset($_POST['element']) auch schon zu einem früheren Zeitpunkt, also dort, wo man den vorgeschriebenen Satzaufbau mit dem übermittelten des Formulares vergleicht.

Ah, jetzt sind wir uns wieder einig.

Wenn das Form dann eine abweichende Anzahl Datenelemente liefert oder Kontrollelemente dabei sind, die gar nicht erwartet wurden, ist es gefaked. Übertagungsfehler kann man in dieser Schicht wohl schon ausschließen. Die würden schon auf IP-Schicht zum Fehler führen (oder doch erst in der TCP-Schicht?).

Kommt auf die Art der Fehler an.

So long,
 Martin

--
Alkohl ist ungesund,
Rauchen ist schädlich,
Sex ist unanständig
- und die Erde ist eine flache Scheibe.