Sessions php et formulaire svp

Bonjour,


J'ai réalisé un petit formulaire dans le but de récupérer les emails de mes visiteurs avec 2 champs: prénom et email.

Jusqu'ici tout va bien le script marche bien, seulement ayant insérer dans le code php une vérification des 2 champs j'ai un petit problème.

En effet quand php vérifie une erreur ou un champ vide celui ci indique au visiteur par un message qu'il manque soit le prénom ou que l'email est invalide.
Si tel est le cas dans ce message d'avertissement un lien de retour au formulaire est disponible.

Donc mon problème est lorsque je clic sur ce lien les 2 champs du formulaire réapparaissent vides, il faut alors tout retaper.

J'aimerai savoir comment faire pour conserver les champs remplis pour que le visiteur n'ai pas à tout retaper de nouveau.

En cherchant j'ai trouvé que les sesions php seraient une bonne solution à mon problème, mais voila je n'arrive pas à savoir où et comment les placer dans mon code avec 1 fichiers html et 1 php que voici:
Modifié par dav71 (08 Sep 2008 - 17:49)

Hello dav71 et bienvenue,

le plus simple est de tout faire sur la même page. Tu pourrais t'inspirer de cette réponse.

En passant et pour conserver une bonne lisibilité des messages sur le forum, il est demandé d'utiliser les balises code pour présenter le code source des exemples.
Pourrais-tu éditer ton message pour te conformer à cette règle de mise en forme ?
Merci d'avance.

Il y a une alternative JavaScript :

<a href="javascript:history.back()" title="Retour">Retour</a>

Yuk! a écrit :
Il y a une alternative JavaScript :

<a href="javascript:history.back()" title="Retour">Retour</a>

Sauf que Javascript peut être désactivé. Autant faire au plus simple...

Salut tout le monde,

Yuk! :
On peut pousser le bouchon plus loin en écrivant un script *.js pour rechercher les erreurs de saisie. Toutefois, je suis de l'avis de Heyoan, mieux vaut utiliser le bon vieux php pour faire ce genre de chose (plus pratique et plus fiable). Je rajouterai également que pour le design, je préfère voir un div ou autre accompagné d'un « ! » ou « * » ou « autres caractères gremlins » à coté de chaque champ erroné qu'une malheureuse fenêtre alerte hors charte graphique.
<<<EDIT
Je parle de la simplicité à mettre en œuvre comparativement aux deux langages. Je me doute que l'on fait de belles choses en *.js. J'ai l'impression que c'est plus délicat à mettre en place. Si le *.js est désactivé, c'est mort
EDIT;

dav71 :
Bien que la solution de Heyoan soit très juste, j'ai saisie que tu préfères renvoyer les messages d'erreur sur une autre page. À mon avis, ce n'est pas une très bonne idée pour une question d'ergonomie. Néanmoins, je peux te proposer de lire ceci afin d'en apprendre plus sur le sujet.

++
Modifié par Nolem (14 Sep 2008 - 21:23)

bonsoir à tous,

je suis plutôt de l'avis d'Heyoan également (faire simple) et utiliser les tableaux GET ou POST ...
Concernant les Sessions je les crée lorsque tout s'est bien passé (identification et authentification)

Si malgré tout tu souhaite (ou doit ) utiliser le javascript , tu dois prévoir de toute façon un script (en php par exemple) au cas où l'utilisateur n'a pas le js activé .

L'avantage est de réduire les transactions "inutiles" avec le serveur et garder l'application coté client pour tes données déjà entré par le visiteur.

Si tu ne peux garder tout sur "la même page" tu peux renvoyés les données en dur dans ton url

$url = "http://mondomaine/mapage.php?nom=htmlentities($_POST['nom'])&email=htmlentities($_POST['email'])";

que tu passes dans ton lien <a>
tu récupères dans ton formulaire avec les varaibles $_POST en tant que valeur des input

.... mais cela risque de devenir un rien "difficile à gérer"
alors au mieux suis les conseils donné dans le post pointé par Heyoan
++
Modifié par kzone (14 Sep 2008 - 21:59)

kzone a écrit :

...
Si tu ne peux garder tout sur "la même page" tu peux renvoyés les données en dur dans ton url

$url = "http://mondomaine/mapage.php?nom=htmlentities($_POST['nom'])&email=htmlentities($_POST['email'])";

que tu passes dans ton lien <a>
...

Par hasard, je me demande s'il est pas préférable de faire ceci :

$nom=urlencode(htmlentities($_POST['nom']));//dans le cas d'un nom composé
$email=urlencode(htmlentities($_POST['email']));

$url="http://mondomaine/mapage.php?nom=".$nom."&email=".$email;

Peut être que je me montre non ?
Modifié par Nolem (14 Sep 2008 - 23:35)

Salut,

Nolem a écrit :

On peut pousser le bouchon plus loin en écrivant un script *.js pour rechercher les erreurs de saisie. Toutefois, je suis de l'avis de Heyoan, mieux vaut utiliser le bon vieux php pour faire ce genre de chose

Pour rappel : PHP et Javascript ne sont pas incompatibles !

Simplement la vérification en PHP est obligatoire alors que celle en JS n'est "que" pour le confort (en plus d'éviter une requête inutile au serveur).

@kzone & Nolem > juste une remarque : htmlentities est inutile et htmlspecialchars suffit amplement à "protéger" les valeurs qui doivent être réaffichées. D'ailleurs dans le cas d'une insertion en base il ne faut utiliser ni l'un ni l'autre mais sauvegarder les données brutes à l'aide de mysql_real_escape_string.

kzone a écrit :

.... mais cela risque de devenir un rien "difficile à gérer"

+1 : surtout que dans cet exemple il n'y a que 2 champs !

Nolem a écrit :

Par hasard, je me demande s'il est pas préférable de faire ceci :

$nom=urlencode(htmlentities($_POST['nom']));//dans le cas d'un nom composé
$email=urlencode(htmlentities($_POST['email']));

$url="http://mondomaine/mapage.php?nom=".$nom."&email=".$email;

Peut être que je me montre non ?

En cas de réel besoin on pourrait se contenter de

$query_string = 'nom=' . urlencode($_POST['nom']) . '&email=' . urlencode($_POST['email']);
$url="http://mondomaine/mapage.php?".htmlspecialchars($query_string);

Le htmlspecialchars ne servant qu'à remplacer les & en &amp;

Je ne faisais que proposer une alternative pour reafficher le page précédente sans perte de données, je n'ai pas dis qu'utiliser cette méthode n'avait que des avantages ...

Mis a part ça, je vois que vous dites beaucoup "Oui mais si js est désactive ..." si on part de ce principe on fait pas grand chose, pas d'ajax, etc.. alors que vous savez autant que moi que javascript peu faire de belles choses, je vois pas pourquoi on devrait s'en privé sous prétexte qu'une minorité d'utilisateurs l'on désactivé. un check à l'entrée du site pour vérifier l'activation de js, apres plusieurs solutions s'offre à nous, afficher un message d'avertissement pour demander à l'utilisateur d'activé ou alors faire une partie sans javascript. Mais ce n'est pas le sujet ...
Modifié par Yuk! (15 Sep 2008 - 16:01)

Yuk! a écrit :

Mis a part ça, je vois que vous dites beaucoup "Oui mais si js est désactive ..." si on part de ce principe on fait pas grand chose, pas d'ajax, etc.. alors que vous savez autant que moi que javascript peu faire de belles choses, je vois pas pourquoi on devrait s'en privé sous prétexte qu'une minorité d'utilisateurs l'on désactivé.

La question n'est pas là.

Personne ne dit qu'il ne faut pas utiliser Javascript ou Ajax. C'est simplement que tu es sur Alsacréations qui, comme tu le sais, est dédié aux standards du Web et à l'accessibilité. Or une page ou une fonctionnalité qui ne fonctionnerait qu'à l'aide de Javascript ne serait pas accessible. Il suffit juste de programmer de telle façon que son usage soit facultatif (en surcouche).

En complément :
Pourquoi certains n'activent pas JavaScript.
Comment bien coder en Javascript.

yuk! a écrit :

....si on part de ce principe on fait pas grand chose...

ben si justement ; partant de ce principe on doit tout faire et justement parce que une minorité on désactivé le JS ... ou pas !

On part du principe que notre application doit répondre à tous les cas de figure.
On ne sait d'ailleurs jamais ce que l'utilisateur va rentrer comme .... comme quoi d'aileurs.

Il n'y a pas longtemps j'ai réalisé un simple formulaire avec tous les scripts qui vont bien de sécurité et autres htmlentites.
Mon boss de l'époque à tester l'application en tapant avec ses 10 doigts n'importe comment .... je me suis dis : "tiens il a changer la marque de ses cigerettes"

Si le gosse de 3 ans du client passe par là et tripote les boutons et fait "exploser" ton application, ben ta super apllication sécurisée et tout vaut rien

Avec un peu de travail tout le monde peut faire une application qui fonctionne dans la plupard des cas .... mais c'est de résoudre les quelques cas qui reste qu'on s'éclate à programmer ...

merci pour les précision Heyoan , toujours un peu de mal à différencier les 2 html.....
Modifié par kzone (15 Sep 2008 - 23:02)