Bonjour
je me suis pas mal inspiré d'un tuto trouvé je sais plus où pour faire un formulaire qui inscrit des infos dans une base MySQL via PHP, et ça va j'ai compris... sauf un truc :
toute la boucle de vérification des infos est contenue dans cette condition :
 
 if (!empty($_POST['posted']))  
{
...
}
 
avec un élément "posted" correspondant dans le formulaire :
 
<input type="hidden" name="posted" value="1" />
 
Appremment c'est facultatif, mais j'aimerais savoir quel est l'intérêt de faire ça.
Merci de me rendre moins idiot  

personnellement je n'en vois aucun, parce que si le but est de vérifier que la requête provient bien du formulaire, ce n'est pas fiable...

c'est ce que je m'étais dit
merci en tous cas

Un champ input hidden est très utile pour stocker un résultat calculé du côté client (javascript), et pour que ce résultat soit transféré au serveur au moment du submit du formulaire.
 
Dans l'exemple indiqué, il est superflu de tester si un champ est vide par ce moyen. Il est plus simple de le faire directement dans le code PHP du côté du serveur.
 
Mais il existe d'autres situations où avoir un champ caché peut rendre service. Par exemple, pour mémoriser si l'utilisateur a appuyé sur tel ou tel bouton qui ne déclenche pas un submit, tel que l'ouverture d'une fenêtre popup d'aide, ce que ne pourrait pas savoir le côté serveur.

c'est souvent utilisé quand c'est la même page qui traite le formulaire et qui l'affiche. Ca permet de différencier quelqu'un qui soumet un formulaire vide de quelqu'un qui n'a pas soumis le formulaire

quand on se retrouve a faire ça, c'est qu'on est en train de produire un joli mélange de traitement de formulaire et d'affichage , la vraie bonne utilisation de l'input hidden est effectivement les chmaps calculés en js, ou por faire suivre des informations sur un formulaire multipage

En Rails (framework Ruby) les input type hidden sont intensément utilisés par le framework pour différencier un checkbox non coché de rien du tout. Ainsi le framework sait que tu as mis un checkbox sur la page mais que l'utilisateur ne l'a pas coché sciemment.

C'est pratique quand tu as par exemple un formulaire sur plusieurs pages pour récupérer les infos des pages précédentes, ou pour avoir dans un formulaire une information qui ne doit pas être visible par le visiteur.

 
Et bein j'espère que tu plaisantes là, parce que comme niveau de sécurité, c'est juste plus élevé que le fait de cacher une info en la mettant de la même couleur que le fond. Non faut arrêter de raconter n'importe quelle connerie à la fin hein..

Moausi bof, j'ai toujours trouvé ce genre de manip un peu lourde parce qu'elle oblige à coller plein d'info dans l'HTML en le rendant encore moins lisible. Alors que c'est tellement simple de stocker tout ça dans les variables de session..

Qui pètent trivialement, ou ne sont pas nécessairement supportées par les UAs

 
Attend je comprend pas trop là.
On parle de passer une information d'une page à l'autre en PHP. J'imagine donc que tu préconises le fait de la passer tout simplement par URL histoire que l'utilisateur soit pas emmerdé avec des histoires de navigateur n'acceptant pas les cookies et de délai d'expiration, non?
Perso je me pose plus trop la question parce que c'est ce que Rails fait tout seul maintenant Mais je me rappelle que quand je touchais au PHP, j'avais plusieurs foi décidé de passer les informations par variables de session vu que de toutes façons le site les rendait obligatoire (il fallait se logger pour naviguer) que le chef était content parce que ça lui laissait une "jolie" url. Donc ça me semblait plutôt une bonne solution  

et des que l'utilisateur ouvre deux onglet ton site te pete a la gueule
edit ( pour la transmission de  données de formulaire multi page )

Effectivement mais en l'occurrence les pages où j'avais beaucoup de données à conserver étaient celles d'inscription, il n'était donc pas, à mon sens, nécessaire de se préoccuper des onglets vu qu'un utilisateur n'est pas sensé créer 2 comptes en // . Maintenant c'est vrai que si un utilisateur devait vouloir le faire, il serait embêté avec ce système.
Bottom line :  Je ne dis pas que le système des sessions est meilleur que celui des paramètres dans l'URL (Sinon je serais pas content avec Rails). Je dis juste que dans certains cas spécifiques il se justifie . Maintenant c'est vrai que c'est pas forcement justifié de le conseiller à un débutant

tu te rends compte que la question d'origine était de stocker des donnée d'un formulaire en input hidden et que tu reponds en disant qu'il faut stocker l'état de l'utilisateur en session ?  
 

Non ce que je dis c'est que quand tu effectues une inscription, il est possible que l'utilisateur doive remplir plusieurs formulaires avant d'être réellement inscrit, et que donc je préconise que dans ce cas particulier, on peut stocker ces informations dans les sessions au lieu de les mettre en input type hidden ou dans l'URL.
Maintenant cette solution ne plaît pas, rien n'empêche d'en utiliser une autre . De toutes façons le créateur du topic a eu des réponses valables, il ne sert donc à rien de continuer a disserter sur le champ d'application de telle ou telle solution, non?

Par l'URL ou par un input hidden, c'est selon

Ca dépend des cas, les sessions c'est puissant mais c'est aussi fragile, puisque ça tente d'émuler une connection stateful sur un protocole stateless, sauf que la connection émulée est globale, donc entre autres si un utilisateur a 2+ tabs sur le site ça peut lui pêter à la gueule (comme indiqué par flo850), j'avais aussi eu de gros problèmes avec en faisant des sites pour mobiles (gateways WAP qui disent qu'elles gèrent les cookies/sessions mais qui balancent tes cookies à la poubelle, ou terminaux ne gérant pas les cookies)

"De toutes façons le créateur du topic a eu des réponses valables, il ne sert donc à rien de continuer a disserter sur le champ d'application de telle ou telle solution, non?"  
 
Comme vous voulez    
 
Bah, ça m'apprend des choses c'est sûr, mais je pense pas (enfin qui sait ? ) avoir à créer des sites complexes un jour... Donc, disons que l'issue du troll n'a pas d'enjeu pour moi    
heu non c'était pas un troll d'ailleurs à la base    
 
allez salut    

Bonjour,
 
J'arrive un peu tard sur la discussion mais voici :
 
Exemple typique d'utilisation des input hidden : les transactions avec Paypal.. Au final 3 éléments sont en actions :
1 le site vendeurs
2 le clients
3 Paypal.
 
Et là les variables sessions sont bien insuffisantes car le clients clique sur un bouton "acheter" il est renvoyer à Paypal et paypal le renvoi sur le site quand la transaction et complète. et là impossible de récupérer des variables sessions.. Donc soit on utilise une base de données soit on envoie des données via un formulaire caché.

oui, mais ça se contourne facilement ça