Vous n'êtes pas identifié(e).
Bonjour à tous,
j'ai un soucis de destruction de variable, je m'explique :
Page1 : Formulaire de recherche listbox A B C
Page2 : Affichage d'une liste de résultats (je stocke avec post session A B Cmes variables de recherches et j'affiche ma liste en fonction)
Page3 : Affichage d'une fiche en fonction de mes sessions stockes (ABC ou A, ou AB, ou BC etc)
Page4 : Affichage d'une autre liste de résultats
Si en Page 3, je décide de revenir au formulaire page 1 pour refaire un nouveau choix, mais que je ne choisis pas B et C par exemple, la session garde quand même BC en memoire, et affiche la Page 2 en conséquence.
Donc je me suis dit, détruisons les sessions ABC dès que l'on est sur le formulaire par :
?>
Mais c'est pareil, il faut que je teste ma session si elle est vide ou pleine avant de la détuire ou j'écris mal mon code ?
Hors ligne
Bonjour,
Une session ne doit pas être détruite avant que l'utilisateur ait fini sur le site ou avant qu'il ait fait un logout. Par contre cela peut se faire sur les variables de session mais pas au sens premier du terme (unset).
Je m'explique.
Une variable de session fait partie intégrante d'une session sur votre site. Elle doit exister globalement (isset) tout au long de la durée de vie de la session (même si techniquement elle est détruite et reconstruite à chaque page). D'ailleurs on peut s'en servir pour tester si la session en cours est légitime ou pas (un hacker qui a récupéré une id de session et qui s'en sert pour naviguer alors qu'il n'est pas authentifié mais c'est un autre sujet où il y a beaucoup à dire). Comment faire alors? si on a par exemple une variable numérique $num défini en session $_SESSION['num']=$num. Pour la reset on peut faire $_SESSION['num']=0 et mettre une valeur >0 quand un choix est fait. On peut de même faire $_SESSION['marque']=""; pour une chaîne de caractères.
Pour la méthode faire un unset est donc à proscrire comme faire un =0 ou ="" direct aussi. Je m'explique.
Une fois que le session_start() est fait, les valeurs stockées des variables de session sont à nouveau disponibles. Il faut avant tout tester leur valeur pour connaître la marche à suivre.
Si toutes les variables sont réinitialisées =0 ; ="" ; = empty alors c'est la première fois que l'on affiche la page. Sinon on prend en compte l'etat des variables pour éventuellement en réinitialiser certaines et pour afficher la page appropriée.
Dernière modification par Jc (25-02-2011 10:37:25)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Merci beaucoup JC pour cette explication sur les sessions.
Je viens effectivement de retirer les 3 unset de mon formulaire et déja, ça fonctionne beaucoup
Mais par contre, je ne peux pas revenir à la page 3 pour ré-afficher la liste car mes sessions sont vide (echo), par contre, sur ma page4, j'affiche mes sessions, mais ma requete ne fonctionne pas ...
Hors ligne
Re
Faudrait voir une copie de l'entête de la page 3, voire même des 4 pages. En cas vous pouvez me les envoyer par mail si la taille est importante histoire de ne pas flood le forum. Comme vous voulez.
Dernière modification par Jc (25-02-2011 13:26:38)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Je t'ai envoyer un message
Pour l'instant, j'avance ... en bien ou mal
Page 3
session_start();
if (!isset($_SESSION['type_r'])) {
$_SESSION['type_r']="";
}
if (!isset($_SESSION['marque'])) {
$_SESSION['marque']="";
}
if (!isset($_SESSION['modele'])) {
$_SESSION['modele']="";
}
//type_r et marque
?>
Jusque la, tout va bien ...
page 4
La, par contre, bizarrement, je fais un test depuis la page 1 à 2 puis 3 en ne faisant passer que la variable en session "marque" pour tester, et j'affiche mes requetes...
Et à la page 4, il récupère toutes mes sessions de description de la page3 soit type_r, marque, modele et les emmenes à la page4 ....
Dernière modification par theavengers (25-02-2011 14:59:39)
Hors ligne
Détails de la page4 sur la requete de réaffichage qui ne devrait reprendre que la variable indiquer lors de la page 1, mais qui récupere des infos on dirait dès de détails de la fiche page3... :
Dernière modification par theavengers (25-02-2011 15:04:05)
Hors ligne
Je t'ai envoyé un mail "texte" au travers de l'interface du forum. Je n'ai pas pu y joindre les fichiers
Hors ligne
Re,
Bon c'est pas grave, je vais quand même te dire ce que j'en pense.
Ce que je te conseille vivement, et ce que je conseille à tous ceux qui développent, débutant ou non, c'est de structurer la logique du code avant de l'écrire. De plus comme je t'ai dit plus haut l'avantage quand une option n'est pas définie, de la mettre =0 ex: $a=0; un test empty($a) retournera la valeur true.
extrait du manuel php
Ce qui suit est considéré comme étant vide (empty):
■"" (une chaîne vide)
■0 (0 en tant qu'entier)
■"0" (0 en tant que chaîne de caractères)
■NULL
■FALSE
■array() (un tableau vide)
■var $var; (une variable déclarée, mais sans valeur dans une classe)
Ce que je te conseille sur chaque page de faire :
Il faut inclure en plus pour gérer ca correctement le paramètre $page pour dire au code sur quelle page il travaille pour optimiser le code correspondant aux tests empty() et obtenir un comportement correct.
Dernière modification par Jc (25-02-2011 18:26:44)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Tu veux dire que je dois avoir uniquement
sur mes pages, je retire par exemple :
Je vais reflechir ce que cela va donner de mettre une session non defini à 0.
Merci, tu va me faire travailler les méninges encore plus ^^
Hors ligne
Re
Pourquoi je prefere mon code au tiens? Parceque si tu mets ce code sur chaque page tu vas rendre l'accès direct à n'importe quelle page de ton appli possible et tu risques ainsi d'avoir un comportement erratique de ton appli.
Dans mon exemple, il faut créer la page n°=0 dans laquelle tu présentes ton appli et tu donnes le lien vers la page 1 de ton appli. Dans la page 0 tu initialise ta session :
Dernière modification par Jc (25-02-2011 16:58:22)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Un grand merci, car malgré tout mes test depuis lundi, j'avoue que je n'avais pas du tout pensé à un accès direct à une de ces pages
Je comprends maintenant ce que tu me dit avec ta dernière explication. Je vais prendre mon temps et digérer ton code.
Merci
Hors ligne
Un bon conseil, il ne faut jamais penser qu'un utilisateur lambda ne connaissant pas l'appli qu'il va utiliser va faire exactement se qu'attends l'application de lui, sinon ca marchera jamais vu que ca n'arrive quasiment jamais. Ce cas de figure s'appele aussi un bug si cela n'est pas prévu.
Dans mon code il faut rajouter au début que si page=0 alors on reroute sur la page de présentation.
Dernière modification par Jc (25-02-2011 17:35:09)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Merci pour tout ces conseils, je vais tenter de les mettre en application. Je vais faire tester l'appli par 2 amis qui n'y connaisse pas grand chose, ça devrait me donner une idée des problemes que je pourrais rencontrer si je la mets en production.
Hors ligne
Très bonne idée. Je te conseille encore cependant de lire ceci Topic developpement, bien que le code que je viens de te fournir en est un bon exemple. Tout ça pour dire que normalement si ton code est bien structuré et pensé, tu ne dois avoir pour ainsi dire pas de surprise dans ce genre de démarche quelque soit l'utilisateur test. En général si il y en a après avoir suivi ce genre de recommendations, les surprises viennent de problèmes de gestion de plateforme, de gestion mémoire, d'optimisation de cache ou de base de données etc... mais pas dans l'utilisation et l'exploitation de l'interface.
Note: en général on fait test son appli quand elle est terminée et qu'elle "semble" fonctionner normalement. Là je pense ne pas me tromper en disant que tu en es encore au stade de la conception^^.
Dernière modification par Jc (25-02-2011 19:09:24)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne