Sommes nous limités sur l'utilisations des variables de sessions et sur le nombre de variables, de taille des données que l'ont peut transmettre par ce moyen la?.
 
les avantages et inconvenients des variables de sessions?
 
quels sont les bonne methodes de transmissions de variables d'une page à une autre?
 
les avantages et les defaut de chacunes de ces methodes?
 
meme question pour les variables globals de type $_POST ou $_GET
 
es-ce mauvais d'abuser des  

 
pour transmettre des variables d'une page a une autre?
 
et pour finir
 
comment faites vous pour passer vos variables (vos valeurs) surtt pour des traitements qui demande beaucoup de valeurs a transferer?
 
et quelqu'un a t-il deja rencontré des probleme d'icompatibilité dans sont site du au changement de $_SESSION et $SESSION_POST_VAR  
ou $_POST et $HTTP_POST_VAR  
puis  "global"  
je trouve que tt ca fini par m'embrouiller un peu le cerveau des fois, peut etre qu'il m'en faut pas bcp mais bon  
Les changements de norme dans un langage complique pas mal l'existence des developpeur et de la maintennace de leur application    
 
enfin voila  
 
dites tous ce que vous avez a dire sur le passage de variables de page en page , foncez
 
ca m'aiderai bien    
 
(peut etre devrais je changer le sujet?    )  

les type=hidden, t'as intérêt à les revérifier à chaque fois parce qu'un petit malin pourrait en profiter pour y glisser des trucs pas bien.
 
Pour les sessions, je dirais que ça dépend si t'en attends beaucoup ou peu. Si c'est peu, abuse, sinon, utilise les type=hidden, ça alourdit un poil la requête mais c'est pas la mort à mon avis.

 
Techniquement oui, les sessions doivent bien être sauvegardée quelque part (fichier ou db en général), donc tu as une limite théorique liées au serveur. Pratiquement, il faut y aller pour l'atteindre...

Les + :
Personnalisation réelle
Meilleure sécurité que les cookies par exemple (stockage sur le serveur, pas chez le client)
Les - :
Durée de vie très brève
Le GC a intérêt à bien faire son boulot, surtout si le serveur est short en espace disque
 

 
Y a pas de bonnes ou mauvaises méthodes, juste des méthodes plus ou moins adaptées suivant les cas
 

 
Je fusionne les deux réponses
Je vois 5 grosses méthodes de transmission (mais il est tard ) :
 

• Cookies :

C'est la méthode pourrie par excellence, désactivable, hébergé chez le client entre autres défauts majeurs. Permets plus d'indentifier une machine qu'un utilisateur

• Formulaire via champs caché :

Pas beaucoup plus sécuritaire que les cookies, les données sont dispo en clair dans le code client et peuvent y être modifiées. Nécessite aussi l'intervention de l'utilisateur pour la transmission (ou le jscript, lui aussi désactivable), bref...

• dans l'url via la query string :

Là, c'est clairement un passage visible, donc à réserver à des données non sensibles (à moins de coder/décoder aux deux extrémités), ça encourage les essais de l'utilisateur (qui tape des QS avec des valeurs "hors cadre" ), bref, ça demande des contrôles d'erreurs avant traitement.

• les sessions :

déjà dit plus haut, deux trucs qui manquent pour moi à php, c'est les sessions globales (session commune à tous les utilisateurs et chargée quelque soit le point d'entrée sur le site) et une meilleure gestion de la portée des sessions

• les caches :

Bon, là je sors un peu du sujet, parce que c'est pas tant une méthode pour passer des variables propres à un utilisateur d'un page à l'autre qu'une réponse aux trucs qui manquent que je cite plus haut =)
 

 
Oui, la syntaxe étant fausse
 

 
Comme dit plus haut, ça dépend beaucoup trop du cas pour dire je fais toujours comme ça. Souvent, c'est session et cache
 

 
Non, j'utilise que les formes courtes

deja c quoi excatement cette faille des  type hiden?
 
 
qu'es vous appeller peu de variables de sessions?
 
admetons que je fais passer environ 10 tableau de plus de 300 élements  chacuns (1element = environ 1 a 80 caractères)
es-ce lourd en session? en hidden? et en cache?
 
naceroth: qu'es t'appelle cache?
 
bon alors si par exemple j'utilise les variables de sessions pour les mots de passes et code clients etc... et que j'utilise les formulaires cachés pour mes formulaires de commandes de produits (code produit , tarifs , quantité etc..) alors je ne suis pas trop un bourrin ?
 
PS : mais des fois ca peu m'arriver de passer bcp d'element par varaibles de session  
 
en fait sur ma 1er page de commande je fais pas mal de requetes et j'affiche le formulaire de comande mais ensuite pour l'affichage du recapitulatif de la commande je transmet tt par formulaire caché ou session  pour eviter de refaire des requettes
 
ais-je tord?
 
bon allé faut que j'aille faire dodo quand meme  ;o)
 
bonne nuit j'attend vos réponses merci d'avancee
puis les cookies j'evite aussi en general , j'aime pas ca non plus  ;o)

Les sessions, c'est très bien mangez z'en !
C'est mieux que les hiddens, sauf si tu as besoin des hidden en question en JavaScript par exemple...
 
Mais y'a rarement besoin de charger les sessions avec des tonnes d'infos.
En réfléchissant un peu, en session, on ne trouve que des infos fourni par l'utilisateur qu'on garde d'une page à une autre avant validation finale. Genre une transaction quoi
Parce-que si c'est pour y mettre des infos qui sont dispo dans une BD ou des fichiers, ben, c'est OK pour des données simples, mais quand ça devient gros, il est temps de se demander s'il ne vaut pas mieux conserver que quelques IDs...
Sinon, y'a les infos de gestion valables tout le temps de la connexion d'un utilisateur identifié. Par exemple une liste de ses droits si il est coûteux de la regénérer à chaque requête HTTP...
 
RMQ : Rien à voir avec PHP en particulier la question !
Le problème se pose pour toute appli WEB

 
Dans le cas présent, des fichiers contenant des données (des tableaux en général) linéarisées.
 
Dans les cas les plus extrèmes (genre tes 10 tableaux de 300 éléments ), je préfères créer un fichier avec un nom aléatoire (basé sur le SID par exemple) et ne transmettre par $_SESSION que le nom du fichier à lire à chaque page plutôt que l'intégralité des données qui ne seront peut être utilisées qu'à la dixième page

 
pour resumer je linearise mes tableaux je les mets dans un fichiers nommé par le SID (que je ne sais aps coment obtebir   )
puis dans ma variable de session je garde le nom du fichier . c bien ca?
 
mais comment ton fichier se supprime a la cloture de la session?

 
c'est vrai aussi que peut etre des fois vaudrait peut etre mieux que je refasse executer des requetes et en gardant juste dans mes variables de session des ID  
 
ttca des fois je trouve que c un vrai casse tete pour savoir quelle moyen utilisé pour les passages de varaibles  . j'espère que c pas que moiq ui est ce genre de casse tete  

pti up

 
explique nous vite fait le fonctionnement global de l'appli, peut-être qu'il y'aura une solution plus simple et performante que ce que tu envisage de faire ?

 
alors ca se decompose en 5 partie  ;o)
 
1) page  login  (authentification)
2) formulaire de tous les produits que l'on peu commander  ( le seul champ que l'on rempli c la quantité
3) recapitumatif de la commande , on voit uniquement les produits que l'on a commandé (presentaion du tarif hors taxe , frais de port etc..)
4) confirmation et enregistrement de la commande
5) version imprimable du bon de comande
ces 5 parties correspondent a des apelels de 5 pages (identiques ou non mais 5 chargements de pages)
 
voila. La gestion du paiment en ligne et la livraion ce fait en interne, pas sur le net
 
je sais pas si deja ca resume un peu mon appli
 
en gros je passe par session mon athentification
 
ensuite pour passer de mon formulaire(2) a mon recapitulatif , je transmet tt ce qui est cod produit , quantité , prix , remise etc.. par formulaire caché  (button caché) , tt ca pour eviter de refaire des requtes a nouveau sur la base et alléger les lignes de code
 
ensuite je repasse ces memes valeurs  (par formulaire caché) sur la partie (3) confirmation de la commande et enregistrement
 
et je repasse ces memes valeurs par formulaires caché au bon de commande imprimable
 
en gros je passe  3 fois les mmes valeurs par formulaire cachés
 
je sais pas si je suis assez clair , je ne sais pas trop quoi donner comme precision supplementaire
 
si ta besoin d'autre info pour que ca soit plus clair n'hesite pas a demander  

 
Je viens de terminer un projet similaire (mais plus gros et plus poussé   ), et franchement en session à part l'authentification, je passe un tableau multi contenant les id des produits commandés, avec à coté leurs couleurs et tailles choisies, aprés le panier se démerde avec ca et la bdd pour trouver les infos et faire le calcul, c'est beaucoup plus simple, le client ne va pas voir son panier toutes les 2s

 
   
 
oauis c vrai mais mon gros probleme ca a était le temps pour le faire, j'ai du faire ca en  5 jours avec recuperation des produits present sur un catalogue gerer avec oscommerce. enfin bon la merde    
 
et la c vrai que si j'ai un tt petit peu de temps je voudrait me pencher sur l'optimisation du code
 
-passage de variable
- CSS
etc..
 
 

 
Y'a deja tout ce qu'il faut dans oscommerce, pourquoi refaire un systeme

 
parceque deja on ne veut pas le paiment et la livraion ensuite la facon dont on ma demander d'incorporer les produits dans oscommerce ne me permet plus d'utiliser le systeme de commnde d'oscommerce  
 
puis ensuite c pour des commande de gros clients  donc faut du rapide en peu de clique  
 
et ensuite la gestion et les bases et pour les mises a jour etc... bin oscommerce n'etait pas simple dans notre cas
 
mais bon le plus gros pb etait la livraion et le paiment que l'on ne voulait pas et qui était difficil a completement degager d'oscommerce mais surtt le probleme etait la facon dont on presente les produits sur le catalogue qui nous permet pas la commande direct a partir d'oscommerce  
 
et pour finir et comme je l'ai dit c'ets pas pour des commandes grand public
 
enfin voila en gros les raisons
 
et puis aussi on veut du tres rapide
et des fois modifier un truc qu'on connait pas bien bin ca prend plus de temps
 
voilou
 
   

 
Ce que tu veux ca ressemble exactement à mon projet
 
Dans ton cas t'aurais dû refaire le catalogue, c'est peut-être plus rapide que de repomper des morceaux d'oscommerce

 
en gros oui, c'est ça
 
Pour la suppresion, c'est la limite du système, pas de GC donc c'est au script (ou à un script d'admin) lui-même de faire le travail. Ceci dit, comme je vide de toutes manières les grosses variables de sessions une fois que j'en ai fini avec elles (sont pas nombreuses les données que tu gardes d'un bout à l'autre de la session ), supprimer une session ou un fichier, c'est choux vert et vert choux

 
ouais c clair, si ca ne tenais que de moi j'aurais refais un mini catalogue, surtout que je n'avais pas besoin de la complexité d'oscommerce, mais bon ils ont voulu quelque chose de tres rapide , et mon chef me la un peu imposer et enfin de compte a cause de ca on c trouvé un peu ds la merde

 
euh c quoi un GC?
 
bin ce que je comprend pas c'est que, si tu supprime tes variables de sessions c'est pas pour autant que tu supprimes ton fichier (cache)?
et pour ca faudrait faire un truc qui supprime les fichiers une fois de temps en temps, ou faire ca a la main.
 
ou alors faudrait quelquechose qui detecte la fin de session et qui supprime le fichier.
 
 

GC : Garbage collector
C'est justement le process qui fait le ménage dans les vielles sessions.
 
Pour les sessions, je préfère utiliser une BD...
 
Edit :  
Détection de fin de session : Impossible sauf avec un lien/bouton "déconnexion" dont on ne peux jamais être certain qu'il sera utilisé.
Un gestionnaire de session fonctionne donc de la manière suivante :
A chaque connexion (voir plus loin) on supprime les sessions non mise à jour depuis un temps paramétrable (généralement autour de 20 minutes).
Plus loin : En fait ce process de supresssion n'est pas lancé systématique. Un paramètre permet de fixer une probabilité de lancement du GC.
 
Sinon, supprimer les variables de session ça sert à limiter le nombre et le volume de variable à charger à chaque page

bon le GC c ce qui regarde si les  variables de sessions etc... sont toujours utilisés , on peu regler ca frequence de controle dans php.ini
 
mais c pas ca qui va permettre de supprimer le fichier si la sessions est fermer , enfin si j'ai bien compris  
 
et le probleme serait le meme si je stock dans une BdD au lieu d'un fichier
   
 
mais peut etre je ne comprend pas trop, je suis un peu novice dans ce domaine

C'est tout à fait ça

Ca doit être pour ça...

 
Ah mais si, si ton tableau de cache est vide, tu peux parfaitement supprimer le fichier correspondant dans le script. Ca gêne pas, si ton utilisateur réutilise un cache par la suite, et bien le fichier est recréé.
 
Mais dans tous les cas, tu peux (dois) coder ton propre GC qui fait le ménage dans les fichiers oui (à chaque connexion à la partie d'administration d'un site par exemple, pour ceux qui sont assez mis à jour )
 
Pour le stockage en db, j'utilise pas (vu que je fais tout pour utiliser le moins possible les db ), mais j'ai déjà vu des classes qui utilisaient de db pour stocker les variables de sessions, et qui possédaient leur propre GC à charger soit même dans un script quelconque
 
Et comme le dit Mara's dad, la suppression des variables de session, c'est juste pour éviter d'alourdir un script avec des tonnes d'infos qui vont plus servir à rien.

Un exemple brut de décofrage (sorti tout droit d'un projet) pour PostGreSql...
 

ouhla j'ai encore beaucoup de boulot je crois et bcp a apprendre et comprendre  

ouhla pareil

vous auriez une bonne doc au sujet de tout ca?
 

j'ai des pistes
 
session_set_save_handler  

La doc !
Y'as celle de PHP sur les sessions, et un exemple pour PGSQL