Weiterleitung mit Variablenübergabe

[startist]

Danke Nobbie, ich fühle mich tatsächlich nicht persönlich angegriffen. Ich verstehe deine Sicht vollkommen. Ich habe ja selber den Antrieb, mich ständig zu verbessern. Das wird auch von Projekt zu Projekt besser. Keiner fängt mit 100 Prozent an.

Du klingst ein bischen wie mein Schwiegervater. Der ist auch ein alteingessener IT-Fachmann und findet sogar C++ misslungen
Das ist natürlich keine Beleidigung, ich kann meinen Schwiegervater gut leiden

Grüße, startist

[Xardas der Dunkle]

, Nobbie ich finde deinen Weg eher Schwachsinnig. Wieso sollte man für jedes dumme Modul eine extra Aufrufseite haben, die dann wieder alle includes tätigt.

Bei einem Programm, hast du auch eine exe Datei mit einer main-Funktion die dann entsprechend auf die Benutzereingabe reagiert und dann die entsprechende Unterfunktion aufruft.
Daher sehe ich gerade absolut nicht den Grund wieso man es in PHP anders machen sollte.

[Nobbie]

:roll:, Nobbie ich finde deinen Weg eher Schwachsinnig. Wieso sollte man für jedes dumme Modul eine extra Aufrufseite haben, die dann wieder alle includes tätigt.

Bei einem Programm, hast du auch eine exe Datei mit einer main-Funktion die dann entsprechend auf die Benutzereingabe reagiert und dann die entsprechende Unterfunktion aufruft.
Daher sehe ich gerade absolut nicht den Grund wieso man es in PHP anders machen sollte.

Damit vergleichst Du aber Äpfel mit Birnen - ein .exe Programm auf dem PC wird nur einmal geladen und läuft dann so lange, bis es beendet wird. Die ganze Userinteraktion findet zur Programmzeit statt, das ganze nennt sich "Conversational Mode".

Bei HTTP Programmierung ist aber das Gegenteil der Fall: das Programm (auf dem Server) bekommt einen Request, sollte diesen so schnell wie möglich abarbeiten, dem Anwender die Daten zur Verfügung stellen und wird dann beendet, ja selbst die Verbindung zwischen Server und Client wird geschlossen.

Nachdem der Anwender seine Daten eingegeben o.ä. getan hat, müssen die Daten wieder zum Server gesandt werden und dort muss, im entsprechenden Kontext, die nächste Seite an den Anwender zurück geschickt werden. Diese zweite Anfrage des Anwenders hat in aller Regel überhaupt keine (oder nur sehr wenige) Gemeinsamkeiten wie die erste Anfrage. Es ist völlig sinnfrei, auf dem Server immer dasselbe Einstiegsmodul zu starten, welches dadurch (ohne Gegenwert) immer größer wird, mit dem man keinerlei Namenskonventionen gerecht werden kann, letztendlich aber wird dann doch die Kontrolle an ein Folgescript weitergereicht, damit das Urscript nicht allzu monolithisch wird - und wozu das ganze? Dieser Modus nennt sich "Transaktions Mode" und wird vollkommen anders programmiert als Conversational Mode.

Wenn Du das schwachsinnig findest, magst Du hier vielleicht diesen oder jenen Anhänger finden, aber wer wirklich Kenntniss von Programmierung (speziell Transaktionsprogrammierung) hat, wird das nicht im geringsten schwachsinnig finden.

[Desmulator]

>Ich finde, wenn mir PHP die Möglichkeit gibt, GET und POST gleichzeitig zu nutzen, dann kann ich das auch tun.

Ich halte es für einen Designfehler im PHP (auch das PHP Development ist nicht feherfrei) und es ist nie ausgeschlossen, dass solche Fehler mal irgendwann rausgebügelt werden - ähnlich wie die Entwicklung der register_globals Geschichte, das war auch mal überhaupt kein Thema, ab PHP6 kann man gar nicht mehr damit arbeiten. Und spätestens wenn vielleicht dieser GET/POST-Widerspruch auch rausgeworfen wird, arbeiten Deine Scripts nicht mehr.

>Ist aus meiner Sicht auch unsinnig, nicht beide Methoden gleichzeitig nutzen zu können.

Es ist völlig unsinnig, weil es ja die Abbildung des HTTP Requests darstellen soll. Und der kann entweder GET oder POST (oder auch HEAD usw.) sein - aber nicht mehrere auf einmal.

Warum darf ich an eine Datei mit Parametern ( GET ) keine Daten ( POST ) senden?

Ich finde sowas absolut schwachsinnig, es ist keine wirkliche Begründung, dass HTTP das anders vorgesehen hat. Wo steht das denn? Wo steht, dass entweder Post oder Get verwendet werden darf? Wäre es, dann würde die Anfrage ja schon schief gehen, bzw. das Protokoll einen Fehler ausgeben!

[Nobbie]

>Warum darf ich an eine Datei mit Parametern ( GET ) keine Daten ( POST ) senden?

Weil es beispielsweise so herum nicht einmal funktionieren würde. Man kann lediglich (leider) beim Request POST auch noch via URL Parameter mitgeben, die PHP (leider) auswertet und als GET Variablen anbietet.

>Wo steht das denn? Wo steht, dass entweder Post oder Get verwendet werden darf?

Das steht in der Definition des Protokolls HTTP, beispielsweise RFC2616. Das hat mit "dürfen" nichts zu tun, sondern so ist es definiert.

Wenn es Dich interessiert (was ich bei Deinem primitivem Wortschatz bezweifle), kannst Du es hier nachlesen: http://www.ietf.org/rfc/rfc2616.txt

[Wiedmann]

Das steht in der Definition des Protokolls HTTP, beispielsweise RFC2616. Das hat mit "dürfen" nichts zu tun, sondern so ist es definiert.

Das steht dort wo genau?

[Nobbie]

>Das steht dort wo genau?

Im Syntaxdiagramm:

The Method token indicates the method to be performed on the
resource identified by the Request-URI. The method is case-sensitive.

Method = "OPTIONS" ; Section 9.2
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token

[Wiedmann]

Im Syntaxdiagramm:

OK, dass ein Request nur den Typ GET oder POST haben kann, darüber sind wir uns glaube ich einig. Hab da leider deinen Post nicht ganz richtig gelesen, sorry.

War erst irgendwie der Meinung, du meintest damit auch, dass es auch keine sogenannten "GET-Variablen" bei einem POST-Request geben darf. Das es diese geben muss, ist ja im Prinzip vorgeschrieben. (Der Name des Arrays $_GET, kann hier natürlich irreführend sein)

[Nobbie]

>Der Name des Arrays $_GET, kann hier natürlich irreführend sein

Die ganzen Arrays sind "unlogisch" in PHP. $_GET sollte besser $_QUERY oder ähnlich heißen, $_FILES ist eigentlich völliger Käse, das ist ja auch kein Request sondern ein Type eines Input Felds usw. - PHP ist eben auch nur "gewachsen".

Wenn aber $_GET und $_POST die Variablen in Abhängigkeit der Methode genannt wurde, dann ist die Koexistenz grausam.

Ich finde allerdings auch die Verwendung von Query-Strings im Action-Attribut von Formularen schlicht grausam - auch wenn "es geht". Sie sind weder notwendig noch sinnvoll.

Was ist eigentlich der Wert von $_GET['x] bei Kollision?

Code: Select all

<form action="blabla.php?x=xxx" method="get">
<input type="text" name="x" value="yyy">
...
</form>


Und (egal wer "gewinnt") - warum gewinnt er?

[Xardas der Dunkle]

Hättest du die POST Methode genommen währe es so:
$_GET['x'] == xxx
$_POST['x'] == yyy
$_REQUEST['x'] == yyy

In diesem Fall dürfte, in $_GET['x'], der Wert aus dem Formularfeld stehen, den wenn das Formular als GET verschickt wird, werden angegebene Parameter im action-string imho ignoriert.
Wobei das eher eine Browsersache ist!

[Wiedmann]

Sie sind weder notwendig noch sinnvoll.

Zum Glück stehst du damit ziemlich alleine da mit dieser Meinung Wie gesagt. Die Variable Querystring (und bei PHP damit auch $_GET), muss bei jedem Request gesetzt werden vom Server, selbst wenn sie leer ist. Bei einem Post-Request kann es dann noch zusätzliche Daten im Request-Body geben. (Die gelangen dann auch auf einem anderen Weg in das CGI-Programm)

Was ist eigentlich der Wert von $_GET['x] bei Kollision? ... Und (egal wer "gewinnt") - warum gewinnt er?

Bei einem GET-Formular in HTML wird nur scheme/authority/path aus der URI im action-Atribute benutzt. Daran wird erst ein "?" drangehängt, und daran dann die Key/Value Paare aus den Formelementen. (17.13.1 Form submission method -> HTML schreibt dem UA das Angängen eines "?" vor)
--> Es "gewinnt" sozusagen "$_GET['x'] == yyy"

Hättest du die POST Methode genommen währe es so:
$_REQUEST['x'] == yyy

Das entspricht zwar dem Standard in PHP, könnte man aber auch ändern, so dass "$_REQUEST['x'] == xxx" das Ergebnis wäre.

[Nobbie]

Zum Glück stehst du damit ziemlich alleine da mit dieser Meinung

Zum Glück liegst Du damit total daneben. Ganz sicher.