nicht angemeldet
GET POST überprüfen, zur vereinfachung nur eine Methode ratsam
Der Martinich übergebe meine Variablem mal mit POST mal mit GET. Hier im Beispiel die Variable mit dem Name NAME
Im Script überprüfe ich dann die Variable
if(isset($_POST['NAME']))
if(isset($_GET['NAME']))
ich würde aber gerne immer nur eine Methode zum überprüfen haben. Kann ich alle POST Variablen automatisch auf GET umwandeln. Oder habe ich eine andere beqemere Möglichkeit dies zu machen.
Kajaran
-
'ǝɯɐu$ ıɥ
ich würde aber gerne immer nur eine Methode zum überprüfen haben. Kann ich alle POST Variablen automatisch auf GET umwandeln. Oder habe ich eine andere beqemere Möglichkeit dies zu machen.
Hä? Schau dir mal den Inhalt von $_REQUEST an.
ssnɹƃ
ʍopɐɥs--
Neurotiker bauen Luftschlösser, Psychopaten wohnen darin und Psychiater kassieren die Miete. -
Hallo,
ich übergebe meine Variablem mal mit POST mal mit GET.
hast du dafür einen guten Grund? Ich halte das nicht für eine schlaue Idee.
ich würde aber gerne immer nur eine Methode zum überprüfen haben. Kann ich alle POST Variablen automatisch auf GET umwandeln. Oder habe ich eine andere beqemere Möglichkeit dies zu machen.
Es gibt noch das Array $_REQUEST, in dem alle Eingaben an das Script zusammengeführt sind, also POST- GET- und Cookie-Werte. Das könnte dir entgegenkommen, obwohl ich sonst eher empfehle, die Werte explizit da abzufragen, wo man sie erwartet.
Ciao,
Martin--
Zwei Kumpels sitzen vor dem Computer. "Welche Suchmaschine beutzt du eigentlich meistens?" - "Prima Vera." - "Hmm, kenn' ich gar nicht." Dann geht die Tür auf: "Schatz ich habe deine Sonnenbrille wiedergefunden!" - "Prima, Vera!"
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
Hallo,
ich übergebe meine Variablem mal mit POST mal mit GET.
hast du dafür einen guten Grund? Ich halte das nicht für eine schlaue Idee.
Auf jeden Fall gibt immer es Gründe, die zur Entscheidung ob der Request-Method führen. Genauso wie es auch Gründe gibt, den Frontend-Controler auf die Request-Method aufzusetzen oder die Parameter unabhängig von der Request-Method abzufragen. Beim Wechsel von einem GET auf POST oder umgekehrt einen Großteil Code umschreiben zu müssen, ist für mich jedenfalls eine grausige Vorstellung.
Hotti
-
Hi!
ich übergebe meine Variablem mal mit POST mal mit GET.
hast du dafür einen guten Grund? Ich halte das nicht für eine schlaue Idee.
Auf jeden Fall gibt immer es Gründe, die zur Entscheidung ob der Request-Method führen.Martin fragte nicht nur nach Gründen, sondern nach guten Gründen. Schlecht überlegte Gründe finden sich immer.
Genauso wie es auch Gründe gibt, den Frontend-Controler auf die Request-Method aufzusetzen oder die Parameter unabhängig von der Request-Method abzufragen.
Wenn du schon beim Bullshit-Bingo mitspielen willst, dann nimm doch die richtigen Begriffe: Front Controller heißt das Ding.
Welche Anwendungsfälle erfordern es denn, dass man nicht gezielt da fragt, wo man die Daten erwartet? Oder auch: wann muss man denn Daten gleichberechtigt auf beiden Wegen erwarten? (Besser gesagt auf drei Wegen, denn die Cookies spielen bei $_REQUEST ja auch mit.)
Beim Wechsel von einem GET auf POST oder umgekehrt einen Großteil Code umschreiben zu müssen, ist für mich jedenfalls eine grausige Vorstellung.
Wie wäre es, sowas gleich von vornherein zu vermeiden? Gemäß der Faustformel: POST bei Requests, die zu Datenänderungen führen und Datenabfragen, bei denen der gleiche Request immer wieder das gleiche Ergebnis bringt, mit GET. Falls man es doch mal ändern muss, dann gibt es Suchen-und-Ersetzen-Funktionen in den Editoren. Das ist ein Handgriff, und wenn es nicht global alles sein soll, kann man in ordentlichen Editoren auch Einzelersetzung mit Bestätigen wählen.
Lo!
-
hi,
Wie wäre es, sowas gleich von vornherein zu vermeiden? Gemäß der Faustformel: POST bei Requests, die zu Datenänderungen führen und Datenabfragen, bei denen der gleiche Request immer wieder das gleiche Ergebnis bringt, mit GET.
Soso, Faustformel ;)
Hier mal ein Beispiel aus meiner Praxis: Navigation über eine große Tabelle, GET-Parameter zum Aufrufen eines Records und POST-Parameter zum Submit von geänderten Daten. Ein Cookie ist auch noch im Spiel, damit der Bearbeiter nach einem POST geänderter Daten wieder auf dieselbe Seite zurückkommt wo er hergekommen ist, dieselben Filter, Suchkriterien hat usw.
Warum sollte ich hier zusätzlich zu den Parametern die Request-Method abfragen, das würde die Kontrollstruktur unnötig aufblähen ohne funktionale Vorteile zu erbringen. Ich regele das alles durch eine zweckmäßige Wahl der Parameternamen und gottseidank ist meinem Parser die Request-Method egal.
Hotti
-
Hi!
Wie wäre es, sowas gleich von vornherein zu vermeiden? Gemäß der Faustformel: POST bei Requests, die zu Datenänderungen führen und Datenabfragen, bei denen der gleiche Request immer wieder das gleiche Ergebnis bringt, mit GET.
Soso, Faustformel ;)Die hab ich ja nicht einfach so erfunden, sondern das ist auch die allgemeine Intention hinter den beiden Methoden: HTML 4.01 Spezifikation - Form submission. Dort ist die Rede von mit und ohne Nebenwirkungen, also GET wenn die Abfrage immer wieder ohne Nebenwirkungen ausgeführt werden kann und POST wenn Nebenwirkungen beabsichtigt sind. Das hat auch Einfluss auf Suchmaschinen und andere Automaten (wie Link-Checker), denn POST-Requests werden üblicherweise nicht ausgeführt, GET-Requests sollten problemlos in x-belibiger Zahl gestellt werden können.
Wer zum Beispiel in einer Liste mit Datensätzen jedem einen Lösch-Link (GET) hinzugefügt hat, sollte sich nicht über eine leere Datenhaltung wundern, wenn er mal sein Angebot nach toten Links absuchen lässt.
Hier mal ein Beispiel aus meiner Praxis: Navigation über eine große Tabelle, GET-Parameter zum Aufrufen eines Records und POST-Parameter zum Submit von geänderten Daten. Ein Cookie ist auch noch im Spiel, damit der Bearbeiter nach einem POST geänderter Daten wieder auf dieselbe Seite zurückkommt wo er hergekommen ist, dieselben Filter, Suchkriterien hat usw.
Passt, GET zum Abfragen, POST zum Ändern.
Warum sollte ich hier zusätzlich zu den Parametern die Request-Method abfragen, das würde die Kontrollstruktur unnötig aufblähen ohne funktionale Vorteile zu erbringen.
Was ist daran unnötig aufgebläht, wenn statt $_REQUEST gezielt $_GET oder $_POST verwendet wird? Es spart ja sogar noch 3 bis 4 Zeichen pro Anwendung ...
Ich regele das alles durch eine zweckmäßige Wahl der Parameternamen und gottseidank ist meinem Parser die Request-Method egal.
Warum ist es dir beim Auswerten egal, wenn du doch die Methoden bestimmungsgemäß im HTML notierst? Du solltest dabei auch beachten, das es erheblich einfacher ist, jemandem einen Link mit Querystring unbemerkt unterzuschieben, der dann mal eben beim Klick unerwünschte Nebenwirkungen erzeugt, nur weil du alles gleichberechtigt auswertest. Natürlich kann sowas in der Praxis nicht passieren, denn für wichtige Dinge hat man ja noch eine Bestätigungsabfrage eingebaut ... ach nee, die bläht ja nur den Code unnötig auf.
Lo!
-
Moin lieber dedlfix,
Ich regele das alles durch eine zweckmäßige Wahl der Parameternamen und gottseidank ist meinem Parser die Request-Method egal.
Warum ist es dir beim Auswerten egal, wenn du doch die Methoden bestimmungsgemäß im HTML notierst?
Sorry, da habe ich mich falsch ausgedrückt: _Meinem Parser muss ich nicht mitteilen, ob ein Parameter 'foo' aus GET oder POST kommt, der Parser liefert mir die Werte unabhängig von der Request-Method; wenn Letztere in einem Script von Bedeutung ist, befrage ich die Umgebungsvariable REQUEST_METHOD.
Hotti
-
Hi!
Ich regele das alles durch eine zweckmäßige Wahl der Parameternamen und gottseidank ist meinem Parser die Request-Method egal.
Warum ist es dir beim Auswerten egal, wenn du doch die Methoden bestimmungsgemäß im HTML notierst?
Sorry, da habe ich mich falsch ausgedrückt: _Meinem Parser muss ich nicht mitteilen, ob ein Parameter 'foo' aus GET oder POST kommt, der Parser liefert mir die Werte unabhängig von der Request-Method; wenn Letztere in einem Script von Bedeutung ist, befrage ich die Umgebungsvariable REQUEST_METHOD.Die REQUEST_METHOD ist bei PHP nebensächlich. Wenn ich Daten per POST erwarte, stehen sie in $_POST - oder auch nicht. Dass dazu ein POST-Request ankommen muss, ist für die Auswertung nicht weiter relevant. Der POST-Request kann ja auch kommen, ohne dass er die erwarteten Daten mitliefert. Üblicherweise fragt man, ob bestimmte Werte in $_POST vorhanden sind und greift dann auf sie zu - fertig.
Bei $_GET ist es ähnlich, nur dass da drin auch Daten stehen können, wenn ein POST-Request abgesendet wurde und ein Querystring angegeben war. Auch hier fragt man nur das Vorhandensein der Einträge in $_GET und ignoriert die REQUEST_METHOD.
Mit $_REQUEST wird die REQUEST_METHOD ebenfalls nicht interessanter, nur dass man hier nicht zwischen Query-String, POST-Daten und Cookies unterscheiden kann. Es bleibt jedoch immer noch, dass man das Vorhandensein der erwarteten Werte prüfen muss. Der Aufwand ist also in jedem Fall der gleiche, nur dass man bei $_REQUEST (etwas mehr zu tippen hat und) drei Datenquellen bunt gemischt abfragt, die man auf der anderen Seite, nämlich beim Formularerstellen und Keks-Erzeugen, separat betrachten muss. Es bleibt die Frage, nach dem guten Grund, es so zu tun?
Lo!
-
-
-
-
-
-
-
Hi!
Im Script überprüfe ich dann die Variable
if(isset($_POST['NAME']))
if(isset($_GET['NAME']))
ich würde aber gerne immer nur eine Methode zum überprüfen haben.Es gibt zwar $_REQUEST, aber das ist nicht die Zusammenfassung von $_GET und $_POST sondern auch noch von $_COOKIE, wobei Werte in $POST gleichnamige Werte in $_GET überschrieben und oben drauf noch $_COOKIE kommt. (Diese Reihenfolge ist konfigurierbar.)
Die Frage ist aber, warum du beides abfragen willst und nicht nur genau das, was du erwartest?
Lo!