> Eine unterscheidbare Variante:
>
> <input type="submit" name="speichern1" value="Speichern">
> <input type="submit" name="speichern2" value="Speichern">
> <input type="submit" name="speichern3" value="Speichern">
Das ist eher suboptimal besser so wie in der PHP-Gruppe bereits gepostet.
<input type="submit" name="speichern[0]" value="Speichern">
> <input type="submit" name="speichern[1]" value="Speichern">
Das läst sich dann auch einfacher auf Serverseite verarbeiten.
> Auswertung in PHP z.B.:
>
> if(isset($_REQUEST['speichern1']) || $_REQUEST['speichern1']!='')
Um Gottes Willen NEIN!
Wer Daten eines Post-Request haben will (ist hier ja offensichtlich der
Fall) der sollte auch $_POST nehmen. $_REQUEST hat da keinen Vorteil
sondern sogar noch den Nachteil das die Herkunft der Daten verwaschen
wird. Aber dazu brauch ich eigentlich nix mehr sagen. Die Diskusion
hatten wir bereits in der PHP-Gruppe.
XPost + FUP nach dclpm gesetzt.
MfG, Ulf
>> Auswertung in PHP z.B.:
>>
>> if(isset($_REQUEST['speichern1']) || $_REQUEST['speichern1']!='')
>
> Um Gottes Willen NEIN!
Bleib mal locker, an den Code ist nichts auszusetzen.
> Wer Daten eines Post-Request haben will (ist hier ja offensichtlich der
> Fall) der sollte auch $_POST nehmen.
Warum? Hat das einen praxisrelevanten Vorteil oder ist die Diskussion
rein akademischer Natur?
> $_REQUEST hat da keinen Vorteil
> sondern sogar noch den Nachteil das die Herkunft der Daten verwaschen
> wird. Aber dazu brauch ich eigentlich nix mehr sagen. Die Diskusion
> hatten wir bereits in der PHP-Gruppe.
Ja, aber dort war man nicht einstimmig der Meinung, dass $_REQUEST
schlecht sei oder von dessen Verwendung abgeraten wird. Es hat "keinen
Vorteil und sogar noch den Nachteil das die Herkunft der Daten
verwaschen wird". Aha. Es hat also keinen wirklichen Nachteil.
VG
Thomas
>> Um Gottes Willen NEIN!
>
> Bleib mal locker, an den Code ist nichts auszusetzen.
Ich bleib locker und trotzdem ist der Code Verbesserungswürdig.
> Ja, aber dort war man nicht einstimmig der Meinung, dass $_REQUEST
Ach herrje. Seit wann ist Einstimmigkeit ein Indikator für ein gutes
Argument bzw. gute Ideen? Offensichtlich hast Du wie einige Andere Auch
das Problem in seinen Grundzügn nicht verstanden. wurde dort alles
durchgekaut. Aber ich hab gar keine Lust mehr Leuten die Problemetik zu
erklären wenn man nicht gewillt ist aus der bereits existierenden
Diskusion vernünftige Schlüsse zu ziehen.
Daher EOD
Das mag sein, muss aber nicht. Abweichende Meinungen pauschal mit "Du
hast nicht verstanden" abzuqualifizieren, halte ich jedenfalls fuer
verfehlt. Ich teile Deine Meinung (in diesem speziellen Fall) absolut
nicht, aber mit solchen Worten wuerde ich trotzdem nicht darueber
schreiben.
> Daher EOD
Soll sein.
Servus,
Stefan (F'up gesetzt)
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Wundervolle Fädchen will das Universum: Stefan!
(Sloganizer)
Praxisrelevant ist auf jeden Fall, dass der Code lesbarer wird - ich
weiss, von woher jemand anderes an dieser Stelle einen Parameter
erwartet. Ausserdem kann ein POST-Wert nicht versehentlich mit einem
GET-Wert überschrieben werden (wer überschreibt da dann eigentlich
wen?). Das hängt jetzt auch davon ab, ob man grundsätzlich den Ansatz
hat, POST & GET für unterschiedliche Zwecke zu verwenden und das für
wichtig hält, was für mich der Fall ist.
Andererseits halte ich die Problematik für weniger zwingend als andere.
> (wer überschreibt da dann eigentlich wen?).
http://de2.php.net/manual/en/ini.core.php#ini.gpc-order
Interessant ist hier neben der Notiz "This option is not available in
PHP 4" der Hinweis auf der Übersichtsseite: "Removed in PHP 5.0.0."
Sollte das nicht eher "Available since..." heißen?
Außerdem:
http://de2.php.net/manual/en/ini.core.php#ini.variables-order
MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
>>> Um Gottes Willen NEIN!
>> Bleib mal locker, an den Code ist nichts auszusetzen.
> Ich bleib locker und trotzdem ist der Code Verbesserungswürdig.
Du dramatisierst halt gerne.
>> Ja, aber dort war man nicht einstimmig der Meinung, dass $_REQUEST
> Ach herrje. Seit wann ist Einstimmigkeit ein Indikator für ein gutes
> Argument bzw. gute Ideen?
Was, ein Geisterfahrer? Tausende!
> Offensichtlich hast Du wie einige Andere Auch
> das Problem in seinen Grundzügn nicht verstanden. wurde dort alles
> durchgekaut.
Ich habe das von dir in dem genannten Thread konstruierte Problem
durchaus verstanden, aber ich für mich ist es keins. Ist auch ok so, ich
muss deine Probleme nicht zu meinen machen. Die ganze Diskussion ist
rein akademisch und interessiert mich daher nicht.
Solange $_REQUEST nicht deprecated ist, und wie Johannes bereits in dem
Thread schrieb ist es das in absehbarer Zukunft auch nicht, ist nichts
falsch daran es zu nutzen. Zumal es keinen Nachteil hat, der praktisch
relevant wäre.
> Aber ich hab gar keine Lust mehr Leuten die Problemetik zu
> erklären wenn man nicht gewillt ist aus der bereits existierenden
> Diskusion vernünftige Schlüsse zu ziehen.
Hätte man in der Diskussion vernünfigte Argumente angeführt, würde ich
vielleicht andere Schlüsse ziehen, aber dem ist nicht so. Das du jetzt
nicht weiter darüber diskutieren willst ist in Ordnung. Damit ist auch
für mich EOD.
VG
Thomas
Thomas Fuchs schrieb:
> Ulf [Kado] Kadner schrieb:
>> Arno Welzel schrieb:
>
>>> Auswertung in PHP z.B.:
>>>
>>> if(isset($_REQUEST['speichern1']) || $_REQUEST['speichern1']!='')
>>
>> Um Gottes Willen NEIN!
>
> Bleib mal locker, an den Code ist nichts auszusetzen.
Unabhängig von Ulfs Kritik bezüglich der Verwendung von $_REQUEST
schmeisst dieses Konstrukt eine Notice falls $_REQUEST['speichern']
nicht definiert ist.
Grüße,
Nico
>>> Auswertung in PHP z.B.:
>>>
>>> if(isset($_REQUEST['speichern1']) || $_REQUEST['speichern1']!='')
>>
>> Um Gottes Willen NEIN!
>
> Bleib mal locker, an den Code ist nichts auszusetzen.
Unabhängig vom ganzen Rest, ist sehr wohl was am Code auszusetzen: Es
müßte && und nicht || heißen. Falls der Index speichern1 nicht in
$_REQUEST existiert, wird geprüft ob der Wert hinterm Index speichern1
im Array $_REQUEST kein Leerstring ist. Das ist unsinn.
Man hätte es auf
if(!empty($_REQUEST['speichern1']))
kürzen können.
Gruß,
Torsten
--
http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8
verschiedenen Datenbanksystemen abstrahiert,
Queries von Applikationen trennt und automatisch die Query-Ergebnisse
auswerten kann.
> Thomas Fuchs schrieb:
>
>>>> Auswertung in PHP z.B.:
>>>>
>>>> if(isset($_REQUEST['speichern1']) || $_REQUEST['speichern1']!='')
>>>
>>> Um Gottes Willen NEIN!
>>
>> Bleib mal locker, an den Code ist nichts auszusetzen.
>
> Unabhängig vom ganzen Rest, ist sehr wohl was am Code auszusetzen: Es
> müßte && und nicht || heißen.
Ich denke eher, es müsste !isset statt nur isset heißen.
Gruß. Claus
empty() ist trotzdem die bessere Wahl. Es faßt beide Prüfungen zusammen. ;)
Gruß,
Torsten
> Claus Reibenstein schrieb:
>
>>>>>> if(isset($_REQUEST['speichern1']) || $_REQUEST['speichern1']!='')
>>
>> Ich denke eher, es müsste !isset statt nur isset heißen.
>
> empty() ist trotzdem die bessere Wahl. Es faßt beide Prüfungen zusammen. ;)
Ein Blick in <http://de2.php.net/manual/en/function.empty.php> sagt mir,
dass Du Unrecht hast. empty() liefert true auch dann, wenn der Wert der
Variablen 0, "0", false oder array() ist.
Gruß. Claus
Und das macht jetzt in diesem Fall genau welchen Unterschied?
Und in diesem *konkreten* Anwendungsfall besteht der Unterschied worin?
> Claus Reibenstein schrieb:
>
>> Torsten Zühlsdorff schrieb:
>>
>>> Claus Reibenstein schrieb:
>>>
>>>>>>>> if(isset($_REQUEST['speichern1']) || $_REQUEST['speichern1']!='')
>>>>
>>>> Ich denke eher, es müsste !isset statt nur isset heißen.
>>>
>>> empty() ist trotzdem die bessere Wahl. Es faßt beide Prüfungen zusammen. ;)
>>
>> Ein Blick in <http://de2.php.net/manual/en/function.empty.php> sagt mir,
>> dass Du Unrecht hast. empty() liefert true auch dann, wenn der Wert der
>> Variablen 0, "0", false oder array() ist.
>
> Und in diesem *konkreten* Anwendungsfall besteht der Unterschied worin?
Im konkreten Anwendungsfall werden Aufrufe der Art
http://www.blah.de/blah.php?speichern1=0 anders behandelt. Solche
Aufrufe sind möglicherweise nicht erwünscht, aufgrund der leichtsinnigen
Verwendung von $_REQUEST jedoch möglich.
Gruß. Claus
Und würden in diesem Fall durch empty nicht weiter beachtet, wie du
selbst das Handbuch zitiert hast.
Aus der Diskussion über die (Nicht-)Verwendung von $_REQUEST habe ich
mich mit Absicht herausgehalten. Ich halte sie für Zeitverschwendung.
Und Zeit ist meine kostbarste Ressource.
Gruß,
Torsten