Discussion :

[ETVigan]

Bonsoir,

J'ai une page - assez compliquée - que je souhaite simplifier !
En fait, il y a 4 étapes qu'une classe itération gère plutôt mal que bien mais mon problème n'est pas là
.
J'ai décidé que d'une page donc d'une transaction ou programme, d'en faire 4.
Je me basais sur le fait qu'il existe le tableau $_POST.

Après la découpe en 4, je me suis rendu compte que soit je me trompais du tout au tout soit le $_POST ne réagissait pas comme je le croyais.
J'avais tout perdu de l'étape I vers I+1 .....

Je ne m'explique pas cela et il y a trop de variables pour utiliser $_SESSION enfin c'est ce que l'on ma toujours dit... que l'espace réservé à cet usage est limité !

Voilà, vous me direz qu'une solution est de sauver sur disque, c'est ce que j'envisage si je ne trouve rien d'autre mais même cela, ce n'est pas si trivial, si facile qu'on le pense....

Voilà mon problème, avez vous des idées à me communiquer ?

Merci à vous car j'ai plusieurs transactions dans le genre.....

[sabotage]

Il n'y a pas de limite de taille de session au niveau de PHP à ma connaissance.

Cependant, si tu as besoin de faire transiter beaucoup de données d'une page à une autre, tu as peut etre plutot un problème de conception de ton site.

[ETVigan]

Le problème n'est pas la taille de $_SESSION mais au départ du tableau GLOBAL $_POST !
Cette "croyance" date de mes débuts dans le WEB et jamais personne ne m'a dit le contraire alors.. vous ètes le 1er !

On m'a tjs dit et mes lectures le confirment que le $_POST conservait les données tant qu'on ne quitte le navigateur ou contraire de $_SESSION et des cookie mais qui ont une période de conservation...

Je me suis trompé où il y a qlqchose que je ne connais pas !
Car si je n'uilise pas le $_POST, j'ai à cette heure les solutions suivantes:

1) Utiliser $_SESSION

2) Faire un swap-in swap-out des variables sur disque entre chaque étapes...

3) Autre suggestion qui ne vient pas....

Mais je reste otimiste, on y arrivera.....

Merci à tous....

[sabotage]

Tu dis que tu ne veux pas utiliser de session a cause d'un probleme de taille, je te dis que ce n'est pas le cas.
Je n'ai pas dit un mot sur la méthode post.

Ce que tu décris a côté, c'est ce que fait une session.

[ETVigan]

Je ne pense pas avoir dit que je ne veux pas utiliser $_SESS, je dis que j'ai appris le WEB avec qlqun'un d'autre et ce qlqu'un m'a tjs fit que....
Et je n'ai jms entendu le contraire sauf hier !
Pour la 1ère X

Et je t'ai posé la question sur $POST que j'utilise dans ce contexte sans pb (mais fans la même "session" de travail sur PC), ce que j'en pense est'il correcte ou non, ou bien j'ai eu du pot dans ces pages là ?

Bonne jounée

[Bebel]

On m'a tjs dit et mes lectures le confirment que le $_POST conservait les données tant qu'on ne quitte le navigateur ou contraire de $_SESSION et des cookie mais qui ont une période de conservation...

Bonjour,
il est fort possible que le navigateur garde les $_POST en cas de retour arrière. Mais le contenu de $_POST n'est accessible que sur la page d'action du formulaire

par exemple dans le cas suivant :
un formulaire poste vers page1.php et on redirige vers page2.php.


page1.php aura les données en post, mais pas page2.php.

Si tu veux avoir les données de la page1 dans la page2, tu dois remettre un formulaire avec des champs hidden dans la page1 qui lui postera dans la page 2.

Et je t'ai posé la question sur $POST que j'utilise dans ce contexte sans pb (mais fans la même "session" de travail sur PC), ce que j'en pense est'il correcte ou non, ou bien j'ai eu du pot dans ces pages là ?

Je pense que tu as eu du pot dans ces pages.

Sinon les sessions ont bien une durée de vie, mais tant qu'il y a de l'activité celle ci est prolongée.

1) Utiliser $_SESSION

2) Faire un swap-in swap-out des variables sur disque entre chaque étapes...

3) Autre suggestion qui ne vient pas....

La solution 3 pourrait être de remettre en caché tous tes champs reçus en post. Au final sur ta dernière page, tu récupère toutes les données dans ton $_POST.

[ETVigan]

Que veux-tu dire par mettre en cash.... ?

[Bebel]

Je suis pas sur d'avoir compris ta question, mais si cela correspond a mettre en caché le post, tu devrais avoir le code suivant

en supposant que page1 recoit les paramètres params1 et params2.
Le code de la page2 serait

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
<form>
<?php 
	foreach ($_POST as $key => $value)
	{
		echo '<input type="hidden" name="' . $key . '" value="' . $value . '"/>';
	}
?>
 
<input type="text" name="params3"/>
...
</form>

[ETVigan]

Je suis de la vieille école de l'informatique, les grosses bécannes et autres... sortit bac+5 en 78 et pour moi la mémoire cash est une sorte de RAM (comme sur un PC d'ailleurs) ou l'OS sauve de façon temporaire ces données et modules appelés par les prog user.....

Alors je ne fais pas la relation avec ton explication, sorry :

[Bebel]

Ok
je pensais que tu parlais de mettre en cache.
Donc je n'ai pas du tout compris ta question, c'etait en rapport de la mémorisation du $_post ou de la session ?

[ETVigan]

Bon, on tourne autour du pot mais on se comprend... avec le temps !

Je ne sais toujours pas si je vais découper ma transaction en 4 en passant les valeurs par $_SESSION ou par transfert sur disque (à développer).....

Pour le moment, je ne vois pas et suis malgré tout novice (bof, pas trop...) en PHP que je ne mange pas encore comme du chocolat belge....

@suivre..... merci

[Bebel]

En même temps la session c'est aussi un fichier écrit automatiquement par le serveur.

Apres si ta crainte d'utiliser une session est la perte de données, tant que l'utilisateur sera actif, tu ne perdras rien.
Apres s'il part pendant une heure en plein milieu du remplissage de son formulaire, la oui tu risque des perdre la session.

[ETVigan]

Ok, je vais changer tout mes $_POST en $_SESSION sauf si je devais changer l'architecture de cette transaction mais cela a des impacts sur d'autres.
Enfin, je veux dire cette nouvelle façon de travailler.... pas + !

@moi de voir..... merci bien !

[grunk]

Comme cela à déjà été dis $_SESSION n'as pas de réel limite de taille (si ce n'est sans doute la limite fixer à php ).

Pour faire un script en plusieurs étapes il y'a en gros deux solutions (qui t'ont été proposer précédemment , mais ca semble pas clair)

1- Full $_POST

Ta page 1 contient le premier formulaire , tu le soumet et tu sérialise le résultat. Tu arrives alors sur la page 2. La page 2 contient son formulaire et en plus un champs caché avec les données du formulaire précédent (ces données que tu auras sérialisé). La page 3 contiendra son formulaire et les données des pages 1 et 2 et ainsi de suite , jusqu' à arriver sur ta page de traitement finale qui récupère le dernier formulaire et dé-sérialise toutes les données des étapes précédente.

2- Mix $_SESSION / $_POST

C'est le même principe que précédemment sauf qu'au lieu de stocker les données dans des champs caché tu les places en session. Ça à l'avantage de pouvoir reprendre à une étape intermédiaire si jamais ta gestion de session le permet.

[ETVigan]

Merci G....

Cela ouvre qlques perspectives mais les données de l'I sont affichées et I+1... ect....

Donc serialize/unserialize à chaque début/fin de transaction puisque le contenu est tjs affiché et susceptible d'être modifié (cela me pose le problème de revenir à l'étape I-x si il y a eu modification...... mais ceci est une autre histoire)

Je résume....
Dans tous les cas, je serialize/unserialize.....

Soit:

1° Je mets le résultat dans une et une seule varaible de session

2° Soit je le mets dans un champ HIDDEN de mon formulaire

C'est bien cela ? Je crois avoir bien pigé......

[grunk]

C'est bien cela ? Je crois avoir bien pigé......

Oui c'est bien cela même si pour les session la serialisation est optionnelle (tu peux très bien faire $_SESSION['monformX'] = $_POST

[gannher]

Pour un formulaire en plusieurs étapes, je pense qu'il vaut mieux mettre les données en session.
Les données dans les champs hidden sont trop facilement modifiable.