J'ai vu des gens (qui écrivent généralement du bon code) modifier directement le $_POST
tableau avec un code comme celui-ci:
// Add some value that wasn't actually posted
$_POST['last_activity'] = time();
// Alter an existing post value
$_POST['name'] = trim($_POST['name']);
// Our pretend function
// Pass the entire $_POST array as data to work with in the function
// The function update_record() will read only the values we actually need
update_record($_POST);
// ...That sure was easier than creating a new array
// with only the $_POST values we actually need.
Il est logique de update_record()
ne pas accéder directement à $ _POST, nous pouvons donc lui passer d'autres tableaux de données, par exemple, mais c'est sûrement paresseux, de mauvaise conception ou peut-être tout simplement faux? Cependant, nous transmettons toujours un tableau valide à update_record()
, alors pourquoi en créer un nouveau?
Ce n'est pas le but de la question, juste un exemple d'utilisation. Cependant, j'ai entendu beaucoup de gens dire que cela ne devrait pas être fait avec des $_REQUEST
données, et c'est une mauvaise pratique. Mais pourquoi? Semble assez inoffensif.
Exemples:
Définition d'une valeur par défaut
$_GET
(ou post) qui n'existe pas vraimentAjout de
$_POST
valeurs qui n'ont pas été réellement publiées après la soumission d'un formulaireAssainissement ou filtrage
$_GET
direct des valeurs ou des clés du tableau très tôt dans le script (assainissement de secours ... pourquoi pas?)Définir une
$_POST
valeur manuellement avant la soumission du formulaire pour remplir une entrée avec une valeur par défaut (lorsque l'entrée lit$_POST
pour sa valeur par défaut; je l'ai fait)Créer vos propres
$_SERVER
valeurs? Bien sûr, pourquoi pas?$_COOKIE
Et les autres, comme et$_SESSION
? Bien sûr, nous devons les modifier directement non? Alors pourquoi pas les autres?
La modification directe des superglobaux ne devrait-elle jamais doit-elle être effectuée, ou est-ce OK dans certains cas?