define + request

[dani_o]

kleines problemchen
ich definiere:

define("number_on","anzeige"); 

nun hab ich ein request - $_REQUEST['number_one'].
Kann ich das definierte "number_one" irgendwie damit aufrufen?
ich hab vieles definiertes, daher möchte ich das per request handeln.
verständlich ausgedrückt?

[hhcm]

Definiert ist definiert. (Falls du versuchst den Wert zu ändern)

Ansonsten nicht verständlich

[dani_o]

lol ne verändern will ich den nicht. es geht um ne sprachdatei. Bsp ist "again" = "noch einmal". Ich lade per ajax eine datei in einen div-container. der soll aber bestimmte definitionen anzeigen, die jedoch immer anders sein können. was er laden soll übergeb ich per request. Bsp.: load=error_one. Nun sollte damit die definition "error_one" aufgerufen werden. Jede einzelne definition mit if $_REQUEST == oder per switch wäre mir zu umständlich ...

[ghostgambler]

Vielleicht suchst du: http://de2.php.net/manual/de/function.constant.php
Wobei ich mir bei der Beschreibung jetzt auch ehrlich gesagt nicht sicher bin...

[jmc]

Dafür ist die Funktion constant() von PHP, aber warum nimmst du nicht einfach ein assoziatives Array?

[fireweasel]

Original geschrieben von jmc
..., aber warum nimmst du nicht einfach ein assoziatives Array?

Listen to that man!!! ;-)
... zumindest, wenn man versucht, aus deiner zweiten "Problembeschreibung" schlau zu werden, liegt der Hinweis mit dem assoziativen Array nahe.

Ansonsten kannst du mit defined() prüfen, ob eine bestimmte Konstante definiert wurde. Ob ein bestimmter Schlüssel ("key") in einem beliebigen Array existiert, kannst du in den meisten[1] Fällen mit isset() herausfinden. Vielleicht hilft dir eines von beiden ja weiter. Ansonsten bitte ich um eine besser verständliche Beschreibung deines Problems.

--
[1] Der Schlüssel ("key") muss ein String sein (is_numeric($key) === FALSE) und der Wert ("value") darf nicht NULL sein.

[h3ll]

Re: define + request

Original geschrieben von dani_o
Kann ich das definierte "number_one" irgendwie damit aufrufen?

Die Frage ergibt irgendwie keinen Sinn. Du kannst keine Definitionen aufrufen, sondern nur Funktionen.

[wave17]

$_REQUEST würde ich nie verwenden! nur POST oder GET!

was wär mit

if (isset($_POST['number_one'])) {
     echo number_one;
} 

[ArSeN]

OffTopic:

---

Original geschrieben von wave17
[B]$_REQUEST würde ich nie verwenden! nur POST oder GET!

weil?

---

[h3ll]

Original geschrieben von ArSeN

OffTopic:

---

weil?

---

Weil es in erster Linie den Code übersichtlicher macht. Man sieht sofort, wo die Werte herkommen bzw. wo sie erwartet werden. Außerdem kann es so nicht zu Überschneidungen von GET-, POST- und COOKIE-Werten kommen.

[ArSeN]

Er sagte aber "nie". Was ist denn, wenn ein Wert mal per POST oder GET kommen kann, wozu dann extra abfragen welches grade gefüllt ist, wenn man auch den Wert aus $_REQUEST nehmen kann?

[Blackgreetz]

@Arsen: Beispiel?
Eigentlich sollte es doch festgelegt sein, wie was kommt..
Warum zwischen beide Varianten nutzen? o.O

mfg

[fireweasel]

Original geschrieben von Blackgreetz
@Arsen: Beispiel?

PHP-Sessions, die ohne Cookies auskommen müssen (die kann man nämlich in einem Browser ganz einfach deaktivieren):

Je nachdem, ob das Web-Seiten-Script per GET (Link, Formular) oder POST (Formular) aufgerufen wurde, kommt die Session-ID mal als GET- und mal als POST-Parameter an.

Eigentlich sollte es doch festgelegt sein, wie was kommt..

Und uneigentlich?
Und warum sollte irgendwer das festlegen?
Der CGI-Standard hat nunmal keine festen Regeln für den Fall, wenn POST- und GET-Parameter übermittelt werden. Im CGI-Modul von Python gilt deshalb GET vor POST, perls CGI::Input
machts genau umgekehrt und PHP hat nunmal diese kaputten superglobalen Arrays.

Warum zwischen beide Varianten nutzen? o.O

Zum Testen/Debuggen von Web-Anwendungen? GET-Parameter lassen sich leicht in der Adressleiste des Browsers eingeben und ansehen. Bei POST-Parametern geht das nicht so einfach.

[ghostgambler]

Der HTTP-Standard sieht mehr oder weniger genau vor, wann welche der Methoden zu nutzen ist. Das wiederum lässt allerdings mindestens genauso viel Spielraum wie die Diskussion, ob eine Navigation jetzt ein Haufen von <p>-Tags, ein <ul> oder ein <ol>, oder auch nur ein Haufen von <a>s sein sollte. Irgendwann kam das auf Basis der REST-Euphorie mal aus den RFCs gekraucht und seitdem gibt es hunderte von nutzlosen geistigen Ergüssen von Menschen, die meinen sie hätten etwas wichtiges zu sagen...

Prinzipiell ist es Jacke wie Hose ob man jetzt $_POST, $_GET oder $_REQUEST nutzt. Hauptsache man weiß was man tut.

[h3ll]

Original geschrieben von fireweasel
PHP-Sessions, die ohne Cookies auskommen müssen (die kann man nämlich in einem Browser ganz einfach deaktivieren):

Je nachdem, ob das Web-Seiten-Script per GET (Link, Formular) oder POST (Formular) aufgerufen wurde, kommt die Session-ID mal als GET- und mal als POST-Parameter an.

Das Session-Handling übernimmt doch vollständig PHP, oder? Warum willst du da die Session-ID mit GET oder POST übergeben?

Original geschrieben von fireweasel
Und uneigentlich?
Und warum sollte irgendwer das festlegen?

Übersichtliches, sauberes Programmieren.

Original geschrieben von fireweasel
Der CGI-Standard hat nunmal keine festen Regeln für den Fall, wenn POST- und GET-Parameter übermittelt werden. Im CGI-Modul von Python gilt deshalb GET vor POST, perls CGI::Input
machts genau umgekehrt und PHP hat nunmal diese kaputten superglobalen Arrays.

Noch ein Grund, warum man auf REQUEST verzichten sollte (wenn es nicht gebraucht wird).

Original geschrieben von fireweasel
Zum Testen/Debuggen von Web-Anwendungen? GET-Parameter lassen sich leicht in der Adressleiste des Browsers eingeben und ansehen. Bei POST-Parametern geht das nicht so einfach.

Doch, geht mindestens genauso einfach.