Super globale
Résolu
aljessy
Messages postés
36
Date d'inscription
mercredi 16 décembre 2009
Statut
Membre
Dernière intervention
4 août 2011
-
12 oct. 2010 à 11:46
aljessy Messages postés 36 Date d'inscription mercredi 16 décembre 2009 Statut Membre Dernière intervention 4 août 2011 - 6 janv. 2011 à 10:52
aljessy Messages postés 36 Date d'inscription mercredi 16 décembre 2009 Statut Membre Dernière intervention 4 août 2011 - 6 janv. 2011 à 10:52
32 réponses
cs_rt15
Messages postés
3874
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
13
16 oct. 2010 à 10:27
16 oct. 2010 à 10:27
Bonjour,
Pour une question php, merci de poster sur phpcs dans un thème php.
Regarde peut être du côté de la session.
[ Déplacé sur phpcs ]
Pour une question php, merci de poster sur phpcs dans un thème php.
Regarde peut être du côté de la session.
[ Déplacé sur phpcs ]
mailliam
Messages postés
261
Date d'inscription
mardi 2 juillet 2002
Statut
Membre
Dernière intervention
10 mars 2014
3
16 oct. 2010 à 13:52
16 oct. 2010 à 13:52
Hello,
moi je ferais plutot un formulaire avec 2 boutons, dont un marqué 'retour' qui renvoie les données sur la page d'avant..
J'ai pas testé mais y a pas de raison que ca ne marche pô
A++
moi je ferais plutot un formulaire avec 2 boutons, dont un marqué 'retour' qui renvoie les données sur la page d'avant..
<form method='post'>
<?php
if (isset ($_POST['submit'])) {
if ($_POST['submit'] == 'Valider 1') {
echo 'Le bouton retour a ete presser';
}
if ($_POST['submit'] == 'Valider 2') {
echo 'Le bouton continuer a ete presser';
}
}
?>
</form>
J'ai pas testé mais y a pas de raison que ca ne marche pô
A++
kohntark
Messages postés
3705
Date d'inscription
lundi 5 juillet 2004
Statut
Membre
Dernière intervention
27 avril 2012
30
16 oct. 2010 à 14:37
16 oct. 2010 à 14:37
Salut,
En tout cas il y en a pas mal pour que le HTML ne soit pas du tout valide :)
Je ne comprends d'ailleurs pas comment ce que tu proposes pourrait répondre au problème de Aljessy (?)
Cordialement,
Kohntark -
J'ai pas testé mais y a pas de raison que ca ne marche pô
En tout cas il y en a pas mal pour que le HTML ne soit pas du tout valide :)
Je ne comprends d'ailleurs pas comment ce que tu proposes pourrait répondre au problème de Aljessy (?)
Cordialement,
Kohntark -
mailliam
Messages postés
261
Date d'inscription
mardi 2 juillet 2002
Statut
Membre
Dernière intervention
10 mars 2014
3
16 oct. 2010 à 21:29
16 oct. 2010 à 21:29
ReHello
j'avais juste mis le principe, voila j'ai refais ma proposition, ca marche super, ou alors je n'ai rien compris à ce qu'il veut faire..
on est d'accord que ce qu'il veut c'est un formulaire sur plusieurs pages et que si l'utilisateur revient en arrière on récupère les données? c'est bien ca?
donc ma proposition est de mettre 2 boutons dont un bouton 'retour':
Par contre je l'ai testé sur FireFox sur linux, j'espère qu'il marche avec IE mais y a pas de raison..
Dis moi si tu pense à une solution + simple :)
j'avais juste mis le principe, voila j'ai refais ma proposition, ca marche super, ou alors je n'ai rien compris à ce qu'il veut faire..
on est d'accord que ce qu'il veut c'est un formulaire sur plusieurs pages et que si l'utilisateur revient en arrière on récupère les données? c'est bien ca?
donc ma proposition est de mettre 2 boutons dont un bouton 'retour':
<html>
<head>
<title>Formulaire 2 boutons</title>
</head>
<form action= "test.php" method="post">
<?php
if (isset ($_POST['submit'])) {
if ($_POST['submit'] == 'retour') {
//le bouton retour à été pressé, affichage du 1er champs avec les données de la variable
echo 'Donnee 1: , ';
echo ', ';
echo '
';
}
if ($_POST['submit'] == 'continuer') {
//le bouton continuer à été pressé, affichage du 2eme champs
echo '<td align=right width=75> Donnee 2: </td>';
echo '<td align =left width= 150> </td>';
echo '';
echo '<td align=left width=300> Vous avez saisi dans le 1er champs: '.$blabla1.'</td>';
echo '</TR></table>';
}
if ($_POST['submit'] == 'Terminer') {
//le bouton Terminer à été pressé, affichage du dernier champs
echo '<td align=right width=100> Merci, formulaire envoyé.. </td>';
echo '<td align =left width= 400> Vous avez saisi dans le 1er champs: '.$blabla1.'</td>';
echo '<td align=left width=400> Vous avez saisi dans le 2eme champs: '.$blabla2.'</td>';
}
}else{
//si aucun bouton n'a été pressé, affichage du 1er champs:
echo '<td align=right width=100> Donnee 1: </td>';
echo '<td align =left width=150> </td>';
echo '</TR></table>';
}
?>
</form>
</html>
Par contre je l'ai testé sur FireFox sur linux, j'espère qu'il marche avec IE mais y a pas de raison..
Dis moi si tu pense à une solution + simple :)
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
19
17 oct. 2010 à 16:24
17 oct. 2010 à 16:24
Salut,
Je crois effectivement que tu n'as pas compris la question. Il ne demande pas comment faire un retour en arrière et garder les données, mais comment garder les données quand un utilisateur clique sur la bouton "Arrière" de son navigateur. Tu noteras que ce n'est quand même pas la même chose... On ne veut pas poster les données à la page précédente, mais revenir à la page sur laquelle il y a le formulaire APRÈS qu'il a été posté.
La solution des sessions est effectivement la meilleure. Le script qui gère les données envoyées doit stocker en session les données envoyées par l'utilisateur. Il faut alors prévoir dans le formulaire l'affichage des données éventuellement présentes en session pour le cas où l'on affiche de nouveau le formulaire. Il faut faire attention à ne pas conserver ces données trop longtemps, il ne faudrait pas qu'elles soient à nouveau affichées après que les données du formulaire aient été entièrement traitées.
Et ton code HTML est toujours aussi peu valide que la première fois.
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
Je crois effectivement que tu n'as pas compris la question. Il ne demande pas comment faire un retour en arrière et garder les données, mais comment garder les données quand un utilisateur clique sur la bouton "Arrière" de son navigateur. Tu noteras que ce n'est quand même pas la même chose... On ne veut pas poster les données à la page précédente, mais revenir à la page sur laquelle il y a le formulaire APRÈS qu'il a été posté.
La solution des sessions est effectivement la meilleure. Le script qui gère les données envoyées doit stocker en session les données envoyées par l'utilisateur. Il faut alors prévoir dans le formulaire l'affichage des données éventuellement présentes en session pour le cas où l'on affiche de nouveau le formulaire. Il faut faire attention à ne pas conserver ces données trop longtemps, il ne faudrait pas qu'elles soient à nouveau affichées après que les données du formulaire aient été entièrement traitées.
Et ton code HTML est toujours aussi peu valide que la première fois.
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
kohntark
Messages postés
3705
Date d'inscription
lundi 5 juillet 2004
Statut
Membre
Dernière intervention
27 avril 2012
30
18 oct. 2010 à 20:40
18 oct. 2010 à 20:40
Je rejoins Neige sur les sessions qui sont toutes indiquées, à moins que ces données ne doivent être persistantes (l'utilisateur reviens 2 jours plus tard les modifiées) Dans ce cas une mise en DB avec authentification du membre semble nécessaire, encore que l'on pourrait gérer ça avec des cookies.
Est ce ton cas ?
Si non je pense que tout le nécessaire a été donné par Neige. Il t'appartient maintenant de mettre en pratique le "micro tuto" de Neige et l'agrémenter à ta sauce.
N'hésites pas à re poster si tu as des difficultés (pense à la doc !!) et des questions concrètes.
Cordialement,
Kohntark -
Est ce ton cas ?
Si non je pense que tout le nécessaire a été donné par Neige. Il t'appartient maintenant de mettre en pratique le "micro tuto" de Neige et l'agrémenter à ta sauce.
N'hésites pas à re poster si tu as des difficultés (pense à la doc !!) et des questions concrètes.
Cordialement,
Kohntark -
mailliam
Messages postés
261
Date d'inscription
mardi 2 juillet 2002
Statut
Membre
Dernière intervention
10 mars 2014
3
17 oct. 2010 à 17:48
17 oct. 2010 à 17:48
Hello,
aah effectivement s'il veut revenir en arrière avec les flèches du navigateur c'est différent.. seulement avec les sessions il faut que ses utilisateurs soient enregistrés..
ah oui? hormis que certains de mes attributs devraient être entourés de guillemets (color="#CC3333") il y a d'autres choses de faux?
car le validateur W3C me signal des choses comme le & dans devrait s'écrire & ou qu'il n'y a aucune déclaration de type de document HTML..
(http://validator.progysm.com/check.php#type187)
Passez une bonne soirée, A++
aah effectivement s'il veut revenir en arrière avec les flèches du navigateur c'est différent.. seulement avec les sessions il faut que ses utilisateurs soient enregistrés..
ton code HTML est toujours aussi peu valide que la première fois.
ah oui? hormis que certains de mes attributs devraient être entourés de guillemets (color="#CC3333") il y a d'autres choses de faux?
car le validateur W3C me signal des choses comme le & dans devrait s'écrire & ou qu'il n'y a aucune déclaration de type de document HTML..
(http://validator.progysm.com/check.php#type187)
Passez une bonne soirée, A++
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
19
17 oct. 2010 à 18:34
17 oct. 2010 à 18:34
Non, pour utiliser les sessions PHP, il n'est pas nécessaire que l'utilisateur soit enregistré. Je t'invite à lire la documentation pour plus de détails.
La validation du code HTML n'est pas le sujet ici, mais bon, je vois pas trop où t'en parler ailleurs...
- les balises doivent être écrites en minuscule
- les attributs doivent être entourés par des guillemets doubles et non des guillemets simples
- les caractères spéciaux comme & doivent être encodés dans les url (& => &). Le caractère & servant justement à définir un caractère encodé, il n'est pas autorisé de l'utiliser seul.
- il faut indiquer la DTD du document. Les spécifications que l'on trouve sur le site w3.org donnent toutes les indications nécessaires. Pour te faire gagner du temps : http://www.w3.org/TR/REC-html40/sgml/dtd.html je cite :
Pour XHTML : http://www.w3.org/TR/xhtml1/dtds.html (les 3 DTDs possibles sont indiquées sur la même page)
- il convient pour parfaire les choses de spécifier l'encodage des caractères. En Europe, on utilise généralement iso-8859-1, iso-8859-15 ou utf-8
- les éléments qui ne sont pas des conteneurs doivent être explicitement fermés, c'est le cas de ou . Exemple :
- selon la DTD XHTML certains attributs sont obsolètes, comme par exemple color ou size pour l'élément qui n'existent plus en XHTML 1.0 Strict.
Mai c'est bien de t'en inquiéter.
Pour revenir à la problématique de départ, voici la marche à suivre :
- formulaire rempli par l'utilisateur. Dans le script PHP, exécuter session_start() avant d'envoyer le moindre caractère de texte.
- => script de traitement des données. Exécuter aussi session_start() avant d'afficher du texte et stocker $_GET dans une variable de session, par exemple $_SESSION['get'] = $_GET Il est inutile à ce niveau là de vérifier les données, les "sécuriser" contre une injection SQL, etc. Si c'est contenu dans $_GET, on peut tout aussi bien les stocker dans $_SESSION.
- si l'utilisateur revient en arrière, il va retomber sur le script qui génère le formulaire. C'est pourquoi, avant d'afficher le formulaire et après avoir démarré la session, il faut récupérer les données contenues dans $_SESSION['get'] si elles existent. Si oui, on les affiche à l'état brut là où elles devraient être... (en enlevant éventuellement les \ qui se seraient glissés là, avec stripslashes() )
Ca donne un formulaire qui ressemble, de loin, à ça :
C'est un peu "crade", mais ça fonctionne. Pour faire plus propre, on peut utiliser une fonction qui affiche la variable si elle existe et qui ne retourne rien sinon. Par exemple :
Dans le formulaire :
On peut s'en dispenser pour le mot de passe.
Il est à noter quand même que cette fonctionnalité est implémentée de base dans Firefox qui est capable de remplir à nouveau le formulaire quand on y revient, peu importe le sens (page précédente ou page suivante). Firefox est même capable de restaurer les données du formulaire après un crash (ce n'est pas une supposition, mais un fait constaté).
Il doit aussi exister des extensions qui gèrent ça encore mieux.
D'une manière générale, il s'agit ici du comportement du navigateur, sur lequel l'auteur d'un site web n'est pas supposé intervenir. Mais il peut être légitime de considérer que l'on souhaite apporter un meilleur confort aux utilisateurs qui n'ont pas un navigateur capable de faire ça de lui-même.
Voilà, c'était ma dissertation du jour.
Bonne fin de week end.
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
La validation du code HTML n'est pas le sujet ici, mais bon, je vois pas trop où t'en parler ailleurs...
- les balises doivent être écrites en minuscule
- les attributs doivent être entourés par des guillemets doubles et non des guillemets simples
- les caractères spéciaux comme & doivent être encodés dans les url (& => &). Le caractère & servant justement à définir un caractère encodé, il n'est pas autorisé de l'utiliser seul.
- il faut indiquer la DTD du document. Les spécifications que l'on trouve sur le site w3.org donnent toutes les indications nécessaires. Pour te faire gagner du temps : http://www.w3.org/TR/REC-html40/sgml/dtd.html je cite :
Typical usage:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Pour XHTML : http://www.w3.org/TR/xhtml1/dtds.html (les 3 DTDs possibles sont indiquées sur la même page)
- il convient pour parfaire les choses de spécifier l'encodage des caractères. En Europe, on utilise généralement iso-8859-1, iso-8859-15 ou utf-8
- les éléments qui ne sont pas des conteneurs doivent être explicitement fermés, c'est le cas de ou . Exemple :
- selon la DTD XHTML certains attributs sont obsolètes, comme par exemple color ou size pour l'élément qui n'existent plus en XHTML 1.0 Strict.
Mai c'est bien de t'en inquiéter.
Pour revenir à la problématique de départ, voici la marche à suivre :
- formulaire rempli par l'utilisateur. Dans le script PHP, exécuter session_start() avant d'envoyer le moindre caractère de texte.
- => script de traitement des données. Exécuter aussi session_start() avant d'afficher du texte et stocker $_GET dans une variable de session, par exemple $_SESSION['get'] = $_GET Il est inutile à ce niveau là de vérifier les données, les "sécuriser" contre une injection SQL, etc. Si c'est contenu dans $_GET, on peut tout aussi bien les stocker dans $_SESSION.
- si l'utilisateur revient en arrière, il va retomber sur le script qui génère le formulaire. C'est pourquoi, avant d'afficher le formulaire et après avoir démarré la session, il faut récupérer les données contenues dans $_SESSION['get'] si elles existent. Si oui, on les affiche à l'état brut là où elles devraient être... (en enlevant éventuellement les \ qui se seraient glissés là, avec stripslashes() )
Ca donne un formulaire qui ressemble, de loin, à ça :
" />
C'est un peu "crade", mais ça fonctionne. Pour faire plus propre, on peut utiliser une fonction qui affiche la variable si elle existe et qui ne retourne rien sinon. Par exemple :
<?php
function form_value($field_name) {
if (isset($_SESSION['get']['login'])) {
echo $_SESSION['get']['login'];
}
}
?>
Dans le formulaire :
" />
On peut s'en dispenser pour le mot de passe.
Il est à noter quand même que cette fonctionnalité est implémentée de base dans Firefox qui est capable de remplir à nouveau le formulaire quand on y revient, peu importe le sens (page précédente ou page suivante). Firefox est même capable de restaurer les données du formulaire après un crash (ce n'est pas une supposition, mais un fait constaté).
Il doit aussi exister des extensions qui gèrent ça encore mieux.
D'une manière générale, il s'agit ici du comportement du navigateur, sur lequel l'auteur d'un site web n'est pas supposé intervenir. Mais il peut être légitime de considérer que l'on souhaite apporter un meilleur confort aux utilisateurs qui n'ont pas un navigateur capable de faire ça de lui-même.
Voilà, c'était ma dissertation du jour.
Bonne fin de week end.
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
mailliam
Messages postés
261
Date d'inscription
mardi 2 juillet 2002
Statut
Membre
Dernière intervention
10 mars 2014
3
17 oct. 2010 à 21:35
17 oct. 2010 à 21:35
Wow merci bcp neige pour ton long message!
C'est vrai que je n'ai jamais vraiment pris le temps de corriger ma syntaxe :)
je vais me pencher la-dessus dès ce soir, sinon j'le ferai jamais
merci encore pour ton mess!!
C'est vrai que je n'ai jamais vraiment pris le temps de corriger ma syntaxe :)
je vais me pencher la-dessus dès ce soir, sinon j'le ferai jamais
merci encore pour ton mess!!
aljessy
Messages postés
36
Date d'inscription
mercredi 16 décembre 2009
Statut
Membre
Dernière intervention
4 août 2011
18 oct. 2010 à 12:07
18 oct. 2010 à 12:07
merci pour vos réponse rapide les amis mais seulement nous ne sommes pas sur la même longueur d'onde. Ce que j'ai omis de préciser c'est que une fois que l'utilisateur à cliquer sur le bouton continuer, il a la possibilité soit de valider soit de modifier et pour celà, je pense que mailliam a une partie de la réponse. mais une fois que ce dernier à valider, il est redirigé vers une page de vérification de champs du formulaire et si pour une quelconque raison il a mal saisir un ou plusieurs champs alors je lui envoie un message d'alert javascript et j'utilise la balise <meta/> pour le renvoyer vers le formulaire de départ en ecrivant echo('<meta http-equiv="refresh" content="1; url=pagededepart"/>');
aljessy
Messages postés
36
Date d'inscription
mercredi 16 décembre 2009
Statut
Membre
Dernière intervention
4 août 2011
18 oct. 2010 à 12:09
18 oct. 2010 à 12:09
et c'est a ce moment que j'aimerais retrouver les valeurs entrées avant de proceder à la vérification.
merci d'avance
merci d'avance
aljessy
Messages postés
36
Date d'inscription
mercredi 16 décembre 2009
Statut
Membre
Dernière intervention
4 août 2011
19 oct. 2010 à 11:31
19 oct. 2010 à 11:31
le problème avec les sessions de Neige est que la variable ne se détruit quasiment pas comme je le souhaitait et j'ai donc ajuster son code en fesant ce ceci :
//Page de départ
if(isset($_GET['modif'])){
$login = $_session['login'];
}
<form method="post" action="verif.php" name="frm">
</form>
//Fichier de vérification (verif.php)
if (isset($_post['modif'])){
$_session['login'] = $_post['login'];
echo ('<meta http-equiv="refresh" content="1; url=pagededepart?modif=1"/>');
}
j'aimerais avoir votre avis sur mon code s'il comporte des failles car jusqu'ici il marche chez moi.
//Page de départ
if(isset($_GET['modif'])){
$login = $_session['login'];
}
<form method="post" action="verif.php" name="frm">
</form>
//Fichier de vérification (verif.php)
if (isset($_post['modif'])){
$_session['login'] = $_post['login'];
echo ('<meta http-equiv="refresh" content="1; url=pagededepart?modif=1"/>');
}
j'aimerais avoir votre avis sur mon code s'il comporte des failles car jusqu'ici il marche chez moi.
kohntark
Messages postés
3705
Date d'inscription
lundi 5 juillet 2004
Statut
Membre
Dernière intervention
27 avril 2012
30
20 oct. 2010 à 21:31
20 oct. 2010 à 21:31
le problème avec les sessions de Neige est que la variable ne se détruit quasiment pas comme je le souhaitait et j'ai donc ajuster son code en fesant ce ceci
Ne le prends pas mal mais je pense que le problème est que tu n'as pas les bases nécessaires à la réalisation d'un script.
j'aimerais avoir votre avis sur mon code s'il comporte des failles car jusqu'ici il marche chez moi.
Lol, j'espère que tu blagues là (???)
Ce code ne peut en aucun cas fonctionner (chez toi ou ailleurs), et pour plus d'une raison.
Mets donc ton baratin de côté, dis clairement que rien ne fonctionne, consulte la doc et les tutos, etc ...
Mais ne vient pas nous faire croire que ton code fonctionne dans le but (?) que l'on te le fasse.
Kohntark -
aljessy
Messages postés
36
Date d'inscription
mercredi 16 décembre 2009
Statut
Membre
Dernière intervention
4 août 2011
21 oct. 2010 à 11:55
21 oct. 2010 à 11:55
To Kohntark:
je n'ai peus etre pas assez de connaissance pour rediger un bon script mais j'en ais assez pour te répondre. n'oublie pas de m'arretez si je me trompe.
N'oublie pas que Neige n'a pas été très explicite. Peu etre pour toi mais pour mois pas.
par exple lorsqu'il écrit " /> à quelle moment il créer la variable session $_session['get'] et ou il créer cette variable? je ne le sais pas. Comment il fait pour détruire la variable juste après son utilisation? je ne le sais pas non plus. Mais je sais une chose c'est que le mien marche et a merveille d'ailleurs. Peut etre on ne se situe pas dans le meme contexte c'est pour celà que tu as un peu de mal à saisir ce que je dit.
J'aimerais bien pouvoir télécharger la doc pour la relire comme tu l'as demander ce qui n'est pas un en soi un mauvais conseil. Si tu l'as déjà télécharger passe la moi ou sinon envoi moi le lien ou je peus le faire
je n'ai peus etre pas assez de connaissance pour rediger un bon script mais j'en ais assez pour te répondre. n'oublie pas de m'arretez si je me trompe.
N'oublie pas que Neige n'a pas été très explicite. Peu etre pour toi mais pour mois pas.
par exple lorsqu'il écrit " /> à quelle moment il créer la variable session $_session['get'] et ou il créer cette variable? je ne le sais pas. Comment il fait pour détruire la variable juste après son utilisation? je ne le sais pas non plus. Mais je sais une chose c'est que le mien marche et a merveille d'ailleurs. Peut etre on ne se situe pas dans le meme contexte c'est pour celà que tu as un peu de mal à saisir ce que je dit.
J'aimerais bien pouvoir télécharger la doc pour la relire comme tu l'as demander ce qui n'est pas un en soi un mauvais conseil. Si tu l'as déjà télécharger passe la moi ou sinon envoi moi le lien ou je peus le faire
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
19
21 oct. 2010 à 12:08
21 oct. 2010 à 12:08
J'ai pas été très explicite... Des fois j'ai l'impression qu'on se fout de ma gueule sur ce forum.
Si tu avais lu mon message EN ENTIER (et pas seulement les passages avec de la couleur) tu aurais trouvé les réponses aux questions que tu poses.
La réponse était là :
C'est pas assez explicite ça ? Tu l'avais lu au moins ce passage ?
A moins que tu n'attendes du code tout frais prêt à copier/coller : C'EST PAS LE GENRE DE LA MAISON !
Là, la réponse de Kohntark était très adaptée : VA LIRE LA DOC !!! Une variable de session n'a pas forcément besoin d'être explicitement détruite (elle se détruira quand la session sera obsolète), à moins que tu aies spécifiquement besoin de vérifier que la variable est vide : utilise la fonction unset() ou bien vide les variables de session : $_SESSION = array(). LA DOC QUOI !!!
Alors là, c'est le comble !!
Tu développes avec un langage et tu ne sais même pas où trouver la doc ? Soit tu es vraiment demeuré (simple hypothèse, hein) soit tu te fous de la gu*** du monde ! http://www.php.net
Tout en haut, un lien "documentation" : c'est pas assez explicite non plus ?
Quand on clique dessus, on a deux choix : "View online" et "Downloads" : Pas assez explicite non plus ?
Fais des efforts et tu verras, tu seras récompensé !
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
Si tu avais lu mon message EN ENTIER (et pas seulement les passages avec de la couleur) tu aurais trouvé les réponses aux questions que tu poses.
à quelle moment il créer la variable session $_session['get'] et ou il créer cette variable?
La réponse était là :
Pour revenir à la problématique de départ, voici la marche à suivre :
- formulaire rempli par l'utilisateur. Dans le script PHP, exécuter session_start() avant d'envoyer le moindre caractère de texte.
- => script de traitement des données. Exécuter aussi session_start() avant d'afficher du texte et stocker $_GET dans une variable de session, par exemple $_SESSION['get'] = $_GET
C'est pas assez explicite ça ? Tu l'avais lu au moins ce passage ?
A moins que tu n'attendes du code tout frais prêt à copier/coller : C'EST PAS LE GENRE DE LA MAISON !
Comment il fait pour détruire la variable juste après son utilisation? je ne le sais pas non plus.
Là, la réponse de Kohntark était très adaptée : VA LIRE LA DOC !!! Une variable de session n'a pas forcément besoin d'être explicitement détruite (elle se détruira quand la session sera obsolète), à moins que tu aies spécifiquement besoin de vérifier que la variable est vide : utilise la fonction unset() ou bien vide les variables de session : $_SESSION = array(). LA DOC QUOI !!!
J'aimerais bien pouvoir télécharger la doc pour la relire comme tu l'as demander ce qui n'est pas un en soi un mauvais conseil. Si tu l'as déjà télécharger passe la moi ou sinon envoi moi le lien ou je peus le faire
Alors là, c'est le comble !!
Tu développes avec un langage et tu ne sais même pas où trouver la doc ? Soit tu es vraiment demeuré (simple hypothèse, hein) soit tu te fous de la gu*** du monde ! http://www.php.net
Tout en haut, un lien "documentation" : c'est pas assez explicite non plus ?
Quand on clique dessus, on a deux choix : "View online" et "Downloads" : Pas assez explicite non plus ?
Fais des efforts et tu verras, tu seras récompensé !
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
aljessy
Messages postés
36
Date d'inscription
mercredi 16 décembre 2009
Statut
Membre
Dernière intervention
4 août 2011
21 oct. 2010 à 13:28
21 oct. 2010 à 13:28
To Neige :
j'envoie mon formulaire avec la method "post".
j'ai constaté que si je creer la variable $_SESSION['post'] = $_POST et si je fais
" /> bien evidement après avoir ecrit la ligne session_start() une fois le traitement éffectuer, lorsque je retourne au formulaire, la valeur de mon champ est toujours là. Raison pour laquelle dans mon fichier de vérification, je passe une valeur en paramètre comme je l'ai indiquer.
je ss aller sur www.php.net mais je n'ai pas la possibilité de télécharger la doc juste de la consulter.
je ne me fous pas de ta gueule. je demande juste si j'ai commis les érreurs dans ma syntaxe.
j'envoie mon formulaire avec la method "post".
j'ai constaté que si je creer la variable $_SESSION['post'] = $_POST et si je fais
" /> bien evidement après avoir ecrit la ligne session_start() une fois le traitement éffectuer, lorsque je retourne au formulaire, la valeur de mon champ est toujours là. Raison pour laquelle dans mon fichier de vérification, je passe une valeur en paramètre comme je l'ai indiquer.
je ss aller sur www.php.net mais je n'ai pas la possibilité de télécharger la doc juste de la consulter.
je ne me fous pas de ta gueule. je demande juste si j'ai commis les érreurs dans ma syntaxe.
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
19
21 oct. 2010 à 13:33
21 oct. 2010 à 13:33
Bravo, tu as réussi à modifier la petite erreur que j'avais commise en utilisant $_GET au lieu de $_POST.
Sauf que tu as manifestement besoin d'apprendre à utiliser PHP avant de développer.
$_POST est un tableau associatif. S'il contient une clé 'login' accessible par $_POST['login'], alors si tu fais $_SESSION['post'] = $_POST cette variable sera accessible dans $_SESSION['post']['login']. Il s'agit d'un tableau associatif, merci de lire la doc à ce sujet. Ca fait partie des bases élémentaires de PHP, si tu ne les maîtrises pas, abstiens toi de développer avec.
Pour la doc, j'ai vraiment, vraiment l'impression que tu ne fais AUCUN effort : http://www.php.net/download-docs.php
Mince quoi, elle est pas cachée cette page ! As-tu seulement lu ce que j'ai écrit ? En haut, lien "Documentation" puis en plein milieu, lien "Downloads". On croit rêver des fois !!
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
Sauf que tu as manifestement besoin d'apprendre à utiliser PHP avant de développer.
$_POST est un tableau associatif. S'il contient une clé 'login' accessible par $_POST['login'], alors si tu fais $_SESSION['post'] = $_POST cette variable sera accessible dans $_SESSION['post']['login']. Il s'agit d'un tableau associatif, merci de lire la doc à ce sujet. Ca fait partie des bases élémentaires de PHP, si tu ne les maîtrises pas, abstiens toi de développer avec.
Pour la doc, j'ai vraiment, vraiment l'impression que tu ne fais AUCUN effort : http://www.php.net/download-docs.php
Mince quoi, elle est pas cachée cette page ! As-tu seulement lu ce que j'ai écrit ? En haut, lien "Documentation" puis en plein milieu, lien "Downloads". On croit rêver des fois !!
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
kohntark
Messages postés
3705
Date d'inscription
lundi 5 juillet 2004
Statut
Membre
Dernière intervention
27 avril 2012
30
21 oct. 2010 à 23:23
21 oct. 2010 à 23:23
Mais je sais une chose c'est que le mien marche et a merveille d'ailleurs. Peut etre on ne se situe pas dans le meme contexte c'est pour celà que tu as un peu de mal à saisir ce que je dit.
Je l'ai déjà dit :
Ce code ne peut en aucun cas fonctionner (chez toi ou ailleurs), et pour plus d'une raison.
La première de ces raisons, et pas des moindres, est que tu as une monstrueuse erreur de parsing (oubli de la fermeture du tag PHP) : aucune configuration au monde ne te le pardonnera; PHP générera une erreur fatale, point barre.
Il y en a encore un paquet, dont les différentes méthodes (GET / POST) qui sont pour le coup parfaitement incompatibles.
De même :
session['login'] ... ça n'existe pas !!
$_session['login'] ... ça n'existe pas !!
$_post ... ça n'existe pas !!
... et je peux encore continuer !
Donc non, ton script ne fonctionne pas du tout.
Si ton formulaire se remplie automatiquement il y a fort à parier que c'est le browser qui s'en charge, comme cela a été évoqué précédemment.
Je me répète donc :
Avant de vouloir coder prend le temps nécessaire pour acquérir un minimum de bases.
Ce forum est là pour t'aider, mais il ne pourra en aucun cas apprendre à ta place.
je ss aller sur www.php.net mais je n'ai pas la possibilité de télécharger la doc juste de la consulter.
Tu as raison, Neige n'a une nouvelle fois pas été suffisamment explicite (il est très connu pour ça)
Il aurait dû te donner ce lien, et t'expliquer qu'il faut que tu fasses un click droit, puis "enregistrer sous ...", ensuite choisir le dossier, etc ... etc ...
Peut être faut il également t'expliquer ce qu'est un click droit et comment enregistrer un fichier ?
faut pas déconner hein.
Dans Google :
"manuel php" => Environ 6 020 000 résultats (0,24 secondes)
"télécharger manuel php" => Environ 266 000 résultats (0,26 secondes)
... j'en passe et des meilleures
C'est binaire :
Soit tu montres clairement que tu fais un minimum d'efforts et tu auras toute l'aide nécessaire.
Soit tu restes dans la fainéantise de ne pas entrer 'manuel PHP' dans un moteur de recherche, ... et tu n'auras que des réponses "adaptées"
Cordialement,
Kohntark -
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
19
21 oct. 2010 à 23:42
21 oct. 2010 à 23:42
Si ton formulaire se remplie automatiquement il y a fort à parier que c'est le browser qui s'en charge, comme cela a été évoqué précédemment.
Je plussoie.
oubli de la fermeture du tag PHP
Arf, j'ai hésité avant de relever... Ce n'est pas une erreur, ça ne génère pas d'erreur et c'est même recommandé par certains frameworks (y compris Zend...). Ne pas fermer la balise php permet d'éviter d'avoir des lignes vides (qui pourraient s'afficher avant l'envoi des entêtes HTTP (je dis pas que c'est une raison valable, je ferme toujours mes balises, mais c'est l'argument avancé dans les "Coding Standards" de Zend).
Par contre :
session['login'] ... ça n'existe pas !!
Manifestement, non... Une constante ne peut qu'être scalaire, par définition.
$_session['login'] ... ça n'existe pas !!
$_post ... ça n'existe pas !!
T'es pointilleux, la syntaxe est correcte, d'un point de vue analyse (parsing). Bon, on sait bien que ce sont des variables qui ne contiennent pas ce que l'utilisateur aimerait qu'elles continssent, mais bon (t'as vu comme je me la pète avec de l'imparfait du subjonctif !?)
Je me répète donc
Tu deviens gaga pon pov' vieux !
Il aurait dû te donner ce lien,[quote]
Du, je ne sais pas, mais pu, oui, je suis effectivement sur un VPN néerlandais ces jours-ci (qui tourne un poil mieux que l'espagnol je trouve).
T'es chez qui toi ? Moi j'ai opté pour Arethusa chez S6N, chiffrement 2048 bits en OpenVPN, qui dit mieux ?
[quote]C'est binaire
Attends, doucement, faut pas submerger l'utilisateur de termes trop complexes, hein. Déjà "en haut de la page" c'est pas clair, alors si tu commences à utiliser la base 2 qui n'est pas franchement naturelle pour l'être humain (certes, on pourrait compter sur ses mains au lieu des doigts, mais on serait quand même très vite limité...)
J'suis déchiré moi.
Ah tiens, Kohntark, j'ai un disciple (t'as vu, j'en profite pour faire genre je suis un maître Jedi, mais demai je serai un maître Vend... euh bref) qui est intéressé pour participer au développement de tu-sais-quoi-même-si-tu-fais-semblant-de-pas-lire-tes-mails (comment j'te vanne lol). Je continue donc de penser que t'es le bienvenu et qu'on est pas pressés pour la mise en ligne (encore qu'en lisant ce genre de fil de discussion, je m'interroge s'il ne conviendrait pas de s'activer pour que ça soit en place à la fin du week end, tellement je sature...)
J'espère n'avoir pas trop fait le casse pieds avec mes HS à la noix, mais j'ai la flemme d'ouvrir un nouveau mail que tu ne liras pas avant 3 semaines, ou d'envoyer un mp dont tu ne seras pas plus au courant que Syndrael qui ne les lis jamais (et qui trouve le même argument que toi pour justifier le délai supplémentaire avant la lecture, à savoir déménagement/travaux... j'vous jure...)
Tchô
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
19
21 oct. 2010 à 23:44
21 oct. 2010 à 23:44
Arf merde,j'ai chié la mise en page... Pffffffffff j'y ai mis du coeur pourtant, mais j'ai eu un excès de confiance en moi et n'ai pas prévisualisé avant de valider...
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
--
Neige
Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)
