Discussion :

[jeff_!]

salut
j'ai un petit probleme avec les sessions, c'est un petit long a expliquer je vais essayer de faire bref

j'ai un bout de code qui fonctionne tres bien si je met un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var_dump $_SESSION);

, mais si je met pas de dump je n(obtient pas le resultat escompter

il faut avoir aussi j'ai redefinit le comportemenrt des sessions, mais elles ont l'air de fonctionner sinon pas grand ne fonctionnerai
je ne comprend pas ce qui ne fonctionne pas, apparement elle aurait besoin d'etre évalué ou en tout cas l'objet que je met en session.

les données de la session sont correcte.
je ne voit pas ce qui peut géné le fonctionnement de mon application??

[Anduriel]

Tu es sous EasyPhp?
Je ne comprends pas l'histoire de ton var_dump(). Si tu en mets pas, ça marche pas?

[jeff_!]

je suis sur un serveur de dev sous unix au boulot

Si tu en mets pas, ça marche pas?

en fait sui je ne met pas mon var_dump, ca fonctionne mais j'ai pas le resultat voulue( et je ne sais meme pas pourquoi ) et mon code a l'air correcte.

je me demande si c'est pas la restauration de la session qui foire, pourtant les donné sont bonne dans le dump.

petit explication sur le fonctionnement;
c'est la partie du framework qui gére la naviagation

en gros on prend des données de l'url, on cherche la page , on execute des filtres.
sur une page j'ai filtre qui redirige vers une autre ( c'est redirection faite en interne, il n'y a pas d'entet envoyé) .

mon probleme c'est que lorsque que je fait le dump, je suis bien rediriger et si je ne le fait pas je vais a la page demandé initialement.

j'espere que c'est plus clair

[Fladnag]

essaye de faire un echo "test"; a la place de ton dump, si ca marche, c'est que tu as besoin d'une "sortie html" pour que ca fonctionne... ce qui veux dire que tu as un comportement différent par la suite (session_start() ou setcookie() ou header() qui ne s'execute pas correctement parce qu'il y a eu une sortie html)

si c'est ca, tu n'arrive pas a diagnostiquer le probleme a cause d'un @ sans doute... qui masque un message d'erreur qui serait utile ici

[jeff_!]

[QUOTE]ssaye de faire un echo "test";/QUOTE]
deja essayé et ca na pas le meme comportement, a mopn avis desphp s'apercoit que c'est un tableau il ne va pas plus loin et il affiche Array

si c'est ca, tu n'arrive pas a diagnostiquer le probleme a cause d'un @ sans doute.

c'est quelque chose que j'ai banis depuis bien longtemps
et j'ai rein pour me mettre sur la piste meme pas une notice

[Fladnag]

hum, si c'est vraiment la lecture des données de sessions qui modifient le comportement... tu dis que tu a redéfini le comportement des sessions... tu as été jusqu'a le modifier avec session_set_save_handler ?

Si c'est le cas, ca voudrais dire que l'execution du callback "read" est necessaire au bon fonctionnement

[jeff_!]

Si c'est le cas, ca voudrais dire que l'execution du callback "read" est necessaire au bon fonctionnement

j'ai bien tenté de rapeller ma mèthod de l'ecture mais rien a faire

[Fladnag]

ah !

Donc si tu as bien modifié session_set_save_handler ca devient compréhensible ;o)

Tu as mis des echo dans TOUTES les methodes de callback définies pour voir lequelles étaient appellées et avec quels parametres lors du var_dump ?

[jeff_!]

je ne les pas fait,
mais si je me souvient bien au demarage de la session php execute la fonction de callback read et le resultat est placé en memoire, la fonction read est éxécuter une seul fois non?

donc elle peut appler par le var_dump( $_SESSIONà) si aucun session_start n'est définie auparavent non?? et das mon cas session_start est bian lancé.
la fonction read est lancé avec les bons parametres er retourne la chaine serializée

[Fladnag]

Note : Le gestionnaire d'écriture n'est pas exécuté tant que le flot de sortie est ouvert. Par conséquent, l'affichage de messages de débogage durant le gestionnaire d'écriture ne sera donc jamais visible depuis le navigateur. Si vous avez besoin de débogage, nous vous suggérons d'écrire vos messages dans un fichier.

Donc essaye quand meme de faire un p'tit fichier de log avec la liste des appels aux différentes fonctions de callback et l'heure d'appel (log aussi l'$id de la session passé aux différentes fonctions)

[jeff_!]

j'ai comme fait les tests avec un log
donc la lecture de la session est effectué au demarage de la sesion et l'ecriture apres la destruction de mon objet framerwork

tout semble normale le var_dump n'appel pas la fonction de callback read etatnt données qu'elle a deja été appelée

[Fladnag]

mmmhhh... donc le log est identique avec ou sans var_dump ? l'ID de la session aussi ? et le comportement est quand meme différent ?

[jeff_!]

mmmhhh... donc le log est identique avec ou sans var_dump ? l'ID de la session aussi ? et le comportement est quand meme différent ?

moui, a moins que ce ne soit pas les sessions qui sont en causes

[Fladnag]

ué, on dirais que ca vient pas des sessions...

mais tu dis aussi que echo "e" ne fait pas la meme chose que var_dump($_SESSION) ...

essaye var_dump("test") ??? (et/ou var_dump(array("test"));

si var_dump("test") fait la meme chose que echo "test", c'est que le probleme vient de $_SESSION

si var_dump("test") fait la meme chose que var_dump($_SESSION) c'est que le probleme vient de var_dump lui meme...

je t'avoue que là je pense qu'on est passé a coté d'un truc, parce que tout ca fonctionne en principe.

[jeff_!]

j'ai effectué les test, et ba toujours pareil
j'ai comparé var_export et var_dump, il non pas le meme comportement, var_export se comporte comme les autes fonctions,

un autre truc c'est en faite c'est que ca fonctionne avec var_dump au bout de la deuxime connection(connection-deconnection- coonnection) donc je pense qu'une variable n'est pas initialisée,

pk il n'ont pas implemeter de teste unitaire Grrr!!

je sens que je vais y passer du temps

[jeff_!]

j'ai peut etre accusé un peu vite les sessions apparenté
une redirection est lancé quand je vais un dump de ma page

surement une redirection javascript