[Résolu] - Récupérer d'un seul coup toutes les valeurs d'un formulai

Bonjour,

Pour récupérer les valeurs d'un formulaire, j'utilise un code du type :

$nom = $_POST['nom'];
$prenom = $_POST['prenom'];
$occupation = $_POST['occupation']; // et ainsi de suite 

Je peux ainsi stocker dans des variables les valeurs des champs de formulaire "nom", "prenom", "occupation", etc.

L'ennui est que je suis en train de construire un questionnaire et que cette méthode est plutôt longue lorsqu'on a plus de 40 champs de formulaire.....

Je cherche une façon d'optimiser le tout, bref, de récupérer d'un seul coup toutes les valeurs du formulaire et de les stocker dans des variables. Toutefois je tiens à ce que ce "traitement par lot" génère (comme l'exemple de code plus haut) des variables nommées de la même façon que les inputs (ex. : <input name="question" ....> --> $question)

Merci à l'avance,
Nalita33
Modifié par nalita33 (26 Sep 2008 - 18:23)

Hello,

extract($_POST);

fait exactement ça.

Petits problèmes de sécurité sous-jacent par contre, ne jamais faire confiance aux données qui arrivent de l'utilisateur.

Tymlis a écrit :
Hello,

extract($_POST);

fait exactement ça.

Petits problèmes de sécurité sous-jacent par contre, ne jamais faire confiance aux données qui arrivent de l'utilisateur.

Qu'entends-tu par problèmes de sécurité? Y a-t-il un moyen de contourner le problème?

hello,

Ca devrait t'aider même si je te conseille d'inclure des échappements pour l'enregistrement de tes données au sein de ta base de données selon le SGBD que tu utilises (type mysql_real_escape_string)

foreach($_POST as $key => $value)
    $$key = $value;

Ca t'évite de re-parser toutes tes variables que tu obtiens avec extract()

see u
Modifié par thoas (24 Sep 2008 - 20:03)

Heu... soyons logique ! A quoi ça sert de passer par des variables intermédiaires alors que tu peux directement utiliser les variables contenues dans le tableau $_POST ?

Tout dépend du point de vue, passer par des variables intermédiaires permet de facilement maintenir son code dans certains cas.
Simple exemple, si j'utilise $_POST['toto'] partout et que je veux changer ma clé, je dois reparcourir tout mon code alors qu'un changement d'une variable aurait été possible si j'étais passé par une variable intermédiaire.

Malheureusement, l'exemple du dessus ne s'applique essentiellement que lorsque la création de la variable ne dépend pas de la clé du tableau $_POST (ce qui n'est pas le cas ici).

Donc tout dépend du point de vue, des préférences de chacun.

Je comprends bien ton point de vue mais, personnellement, je trouve que c'est une mauvaise pratique.

Hum, habituellement, lorsque j'utilisais ma "forme longue" (voir premier post), j'incluais un ISSET pour ne pas avoir de message d'erreur du serveur. Ex. :

<?php if (isset($_POST['nom']))
{$nom = $_POST['nom'];}
else {$nom = false;}  

 if (isset($_POST['ville']))
{$ville = $_POST['ville'];}
else {$ville = false;}  ?> 

J'ai essayé d'appliquer le isset au code de Thoas, mais je n'y suis pas parvenue. Comment appliquer le isset sur ce code? :

foreach($_POST as $key => $value)

    $$key = $value;

Merci encore

foreach($_POST as $key => $value) $$key = $value;

a exactement le même effet que extract($_POST); et pas besoin de tester isset avec cette technique vu qu'elle ne s'applique qu'aux éléments qui sont déjà présents dans $_POST

Le problème de sécurité que j'évoquais et si un petit malin "modifie" ton formulaire de départ pour envoyer de nouvelles informations en post, il peut plus ou moins modifier n'importe quelle variable de ton script
S'il ajoute un champ "admin" et qu'il y mets une valeur de 1 et que toi tu fais ensuite dans ton code un simple test if ($admin) { super code destiné qu'aux admin}, alors il aura accès à tout.

Vouloir automatiser cette définition des variables est dangereux car n'importe quelle variable sera transformée (c'est le même probleme avec le foreach($_POST) hein.
Ta méthode premiere, bien que plus longue est plus sure, seules les variables que tu a définie seront utilisées, les autres ne seront pas modifiées.

C'est noté, je vais réessayer
Modifié par nalita33 (26 Sep 2008 - 06:16)

extract($_POST) a le même effet oui, mais si on veut échapper ses variables pour les insérer dans une base de données, on doit toutes les reprendre une à une donc on arrive à la problématique du départ.

Je suis d'accord avec toi pour dire qu'automatiser est généralement dangereux mais pour ce qui est de ton exemple d'admin, on ne fait généralement pas de test de ce type sur des variables transmises en POST (sur des SESSIONS à la limite).

Pour finir, si tu veux vraiment pas automatiser mais également ne pas faire les affectations une à une, tu peux très bien rassembler tes clés dans un tableau :

$keys = array('nom', 'prenom', 'occupation');
foreach($keys as $key)
    $$key = $_POST[$key];

De cette façon, tu prends uniquement les clés qui t'intéressent et tu conserves la possibilité de les manipuler avant.
Modifié par thoas (26 Sep 2008 - 16:19)

thoas a écrit :
extract($_POST) a le même effet oui, mais si on veut échapper ses variables pour les insérer dans une base de données, on doit toutes les reprendre une à une donc on arrive à la problématique du départ.

Je suis d'accord avec toi pour dire qu'automatiser est généralement dangereux mais pour ce qui est de ton exemple d'admin, on ne fait généralement pas de test de ce type sur des variables transmises en POST (sur des SESSIONS à la limite).

Pour finir, si tu veux vraiment pas automatiser mais également ne pas faire les affectations une à une, tu peux très bien rassembler tes clés dans un tableau :

$keys = array('nom', 'prenom', 'occupation');
foreach($keys as $key)
    $$key = $_POST[$key];

De cette façon, tu prends uniquement les clés qui t'intéressent et tu conserves la possibilité de les manipuler avant.

Sachant que $_POST était une variable globale (donc un array), je pensais justement à mettre en oeuvre la solution que tu viens de proposer, c'est-à-dire de faire mon propre array en spécifiant les différents noms de variables. De toute façon, comme tu le dis, je devrai tout reprendre mes variables pour le transfert sur la BD. Merci!

Tu as beaucoup de possibilités à toi de choisir laquelle est selon toi la plus confortable pour travailler.

A savoir que la meilleure solution est, de mon point de vue, d'utiliser un framework ORM (necessite un temps d'adaptation) :
- Doctrine
- Propel

Bon courage.
Modifié par thoas (27 Sep 2008 - 11:35)

thoas a écrit :
A savoir que la meilleure solution est d'utiliser un framework ...

Hum ... un peu simpliste ...

yodaswii a écrit :


Hum ... un peu simpliste ...

En quoi c'est "simpliste" selon toi? Loin de moi l'idée de partir dans un grand débat mais j'aimerais connaître les raisons.
Modifié par thoas (27 Sep 2008 - 13:24)

Bonjour,

thoas a écrit :
En quoi c'est "simpliste" selon toi? Loin de moi l'idée de partir dans un grand débat mais j'aimerais connaître les raisons.

Certes l'utilisation d'un framework peut être une bonne solution mais le choix d'y avoir recours doit avant tout s'appuyer sur un besoin fondé et réfléchi ... on ne peut pas dire que le choix d'un framework est une meilleure solution par rapport à une solution faite à la mano.

Dans le cas de nalita33, cela ne se justifie clairement pas ... pour imager : cela reviendrait à écraser une mouche avec un bulldozer.
Modifié par yodaswii (27 Sep 2008 - 13:41)

re,

Tout dépend de l'utilisation oui, mais je nuancerais ces propos sur le fait que les framework ORM sont beaucoup moins des usines à gaz qu'il y a quelques années grâce notamment à l'utilisation de PDO.

Concernant la "solution faite à la mano" la plupart du temps elle utilise l'extension mysql de PHP qui est, il faut se le dire, obsolete face à PDO ou Mysqli :
- requête multiple autorisée
- ne prépare pas les requêtes (perte de performance)
- Injection SQL (dans le cas d'oublie du mysql_real_string_escape)

Le but de mon dernier post n'était pas de forcer l'utilisation de ces libraries, mais d'offrir des alternatives plus facilement maintenable dans le cas de table qui contiennent beaucoup de colonnes.

Pour finir, je dirais que c'est l'éternel débat "framework ou pas framework" et pour ne pas rentrer dans celui-ci (malgré que je l'ai initié sans faire exprès) ce sera mon dernier post.

Néanmoins, tes arguments se valent.