Discussion :

[Invité]

Bonjour,

Quelqu'un connaît-il (ou a déjà mis en oeuvre) un autre moyen que les sessions PHP pour conserver un objet PHP 5 entre plusieures pages ?

Merci !

[titoumimi]

il faut rajouter serialize

[gorgonite]

euh... y aurait pas plus simple ?


par exmple, si on definit la classe au dessus du session_start(), on peut se servir de l'objet place dans la variable de session, sans rien de plus...

[Alexandre T]

Non, et c'est ce qu'il vous est précisé par la fonction serialize() et unserialize().

dans la page 1 :

Code :

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

1
2
3
4
5
6
 
<?php
//$lo_objet est un objet de votre cru
session_start();
 $_SESSION['votre_objet']=serialize($lo_objet);
?>

Dans la page suivante :

Code :

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

1
2
3
4
5
6
 
<?php
//EDIT : On suppose que la classe de l'objet est déjà décrite
session_start();
$lo_objet= unserialize($_SESSION['votre_objet']);
?>

Une donc sur la sérialisation des objets : http://fr.php.net/manual/fr/language...ialization.php

[jeff_!]

les objets son serializés automatiquement
le seul a faire gaffe c'est d'appeler la definition de la fonction avant l'appel de session_start

[Alexandre T]

les objets son serializés automatiquement
le seul a faire gaffe c'est d'appeler la definition de la fonction avant l'appel de session_start

J'ai un vieux doute là, et aucun php pour faire un test...

Tu es sûr que la définition de la classe doit précéder le session_start() ? Je pense qu'elle doit juste précéder la fonction unserialize();

D'ailleurs plus j'y pense, plus je me dis que ça doit uniquement précéder la fonction unserialize() puisqu'on peut stocker l'objet dans un fichier !

[jeff_!]

moi je n'utilse pas serialize et unserialize
donc quand on declare session_start php essaye de reconstruire l'objet et si il le connait pas ca plante
maintenant si utilise les fonction serialize et unserialize je me demande quel tete a l'objet au demarrge de la session

[Yobs]

Selon la doc php.net, l'utilisation de la fonction session_register() linéarise automatiquement un objet lors de sa création et le délinéarise lors de sa récupération. Aucune info sur l'utilisation de $_SESSION pour définir ses variables de sessions.

doc: http://fr3.php.net/manual/fr/languag...ialization.php

[gorgonite]

Non, et c'est ce qu'il vous est précisé par la fonction serialize() et unserialize().

bizarre, j'ai un site complet en php 5.0.??? qui marche avec cela

[Alexandre T]

Oh my god !

J'ai cru que l'enfilade était créé par toi, gorgonite, et que tu te plaignais que deux fonctions étaient trop long ! Autant pour moi ! Je n'utilise jamais session_register, j'ignorais totalemen que cela serialisais automatiquement.

[ePoX]

Quelqu'un connaît-il (ou a déjà mis en oeuvre) un autre moyen que les sessions PHP pour conserver un objet PHP 5 entre plusieures pages ?

Pour en revenir au post... Oui... Une bdd, un fichier xml, un fichier au format de ton cru ou que sais je encore.

Mais quelque soit la méthode de sauvegarde de l'objet entre deux pages, il faudra bien à un moment être capable de regénérer le bon objet pour le bon client, donc la session interviendra surement quelque part.

A moins que ce ne soit un objet partagé ou unique..

bbye

[Eric80]

Pour converser une variable entre plusieurs pages, est on obligé de passer par les sessions? La variable est elle alors forcément stockée sur le HDD ?
Pour ma part, il s'agirait d'une table temporaire SQL en PHP4/MySQL 4.0

[Alexandre T]

Il existe une fonction session_set_save_handler(). qui te permet de désigner la fonction qui gère les insertions dans les variables de sessions. Donc tu peux faire ce que tu veux des valeurs que tu passes en session.

[Invité]

Pour en revenir au post... Oui... Une bdd, un fichier xml, un fichier au format de ton cru ou que sais je encore.

Mais quelque soit la méthode de sauvegarde de l'objet entre deux pages, il faudra bien à un moment être capable de regénérer le bon objet pour le bon client, donc la session interviendra surement quelque part.

A moins que ce ne soit un objet partagé ou unique..

bbye

Salut,

Merci pour cette réponse, c'est en faite ce que je voulais savoir. J'étais au courant pour la linéarisation (serialization) des objets, j'ai évidemment consulté le manuel PHP avant de poster ce mess.

En faite, il s'agit d'un objet qui doit être transmi en paramètre à une autre classe (membre), dans une autre page.

Le problème est le suivant :

J'ai créé deux classes :

• Formulaire.class
• FormulaireControl.class

La première classe génére un objet formulaire XHTML.

Extrait de code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
 
<?php
 
classe Formulaire
{
 
   // Variable membre comportant le "prototype" de chaque champ créé.
   private $fields = array();
 
   // Paramètres usuels pour la balise XHTML <form>
   public function __construct($method, $action, $enctype = NULL)
   {
     // ...
   }
 
   // Méthode d'exemple
   public function inputText($title, $name, $size, $default_value = NULL,     $maxlenght,  $minlenght, $excepted_value, , $format = "%s")
   {
     // Création de la chaine de caractère XHTML
    $output = '<label>'.$title.'<br /><input type="text" name="'.$name.'" size="'.$size.'" maxlenght="'.$maxlenght.'" />
    
    // Assignation du "prototype" du champ dans la variable membre
     $this->champs = array($name => array($name, $maxlenght, $minlenght, $excepted_value));
    
    // Affichage de l'XHTML.
    return printf($format, $output);
  }
 
  // Cette fonction pourrait être "protected".
  public function getChamps
  {
    // Accesseur 
    return $this->champs;
  }
}
 
?>

Il s'agit de la classe en très très simplifié. Pour chaque type de champ (ici input text) il y a une méthode comportant un certains nombre de paramètres :

• Les paramètres relatifs à la balise ($name, $size, $default_value, $maxlenght)
• Les paramètres relatifs au type de champ ($maxlenght, $minlenght, $excepted_value), il s'agit du "prototype" du champ.

En gros, les paramètres relatifs à la balise son affichés pour l'utilisateur, tandis que les autres sont sensés restés des paramètres "privés" pour la seconde classe, celle qui contrôle les saisies du formulaire :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
<?php
 
classe FormulaireControl extends Formulaire
{
 
   public function __construct(Formulaire $objet)
   {
     $this->champs = $objet->getChamps();
 
     /* ...  Divers tests de comparaison, si il y a une erreur de saisie dans un
champ, cette classe pour directement regénérer le champ incriminé pour l'utilisateur */
   }
}
 
?>

Une instance pourrait ressembler à ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
 
<?php
  // Page 1
 
 session_start();
 
 $form = new Formulaire('post', 'page_2.php');
 $form->inputText('Un champ', 'champ', 32, 'Ecrivez ici', 64, 1, 'char');
 
 // Bouton "Envoyer".
 $form->inputSubmit(); 
 
 $_SESSION['$form'] = serialize($form);
 
?>

1. Ce champ a pour titre "Un champ" (<label>Un champ)
2. Son identificateur s'appelle "champ" (<input name="champ">)
3. La taille de la zone de saisie est de 32 (<input ... size="32">)
4. La valeur par défaut est "Ecrivez ici" (<input ... value="Ecrivez ici")
5. Nombre de caractère maximal "64" (<input .. maxlenght="64")
6. Cette même valeur est passé en paramètre pour le contrôle du formulaire (étant donné que l'attribut XHTML maxlenght est facilement contournable).
7. Ensuite, le nombre de caractère minimum (ici "1" : signifie que le champ ne peut pas être vide).
8. Le type de valeur attendu (ici "char" correspondrait à une chaine de caractère, mais ce champ pourrait être remplacé par une classe PCREdu genre [:alphanum:], [a-z], etc...

L'objet "$form" doit être transmis sur une seconde page :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
<?php
 
 // Page 2
 
 session_start();
 
 $form = unserialize($_SESSION['$form']);
 
 $control  = new FormulaireControl($form); 
 
?>

Voilà, désolé pour toutes ces explications, mais pas moyen d'exposer le problème autrement ...

La question que je me pose par rapport à tout ça, c'est de savoir si l'intégrité d'un objet peut-être garantie lorsque il est transmi par SESSION PHP.

Car dans le cas contraire, si certains paramètres de l'objet sont modifiés (modifiables), je ne peux pas faire confiance aux "prototypes" pour effectuer les controle des saisises (de manière dynamique)...

Autre chose, si je choisis d'utiliser une base de donnée pour stocker les valeurs d'une session, il serait peut-être plus pratique d'utiliser sqlite (table temporaire) plutôt qu'une base mysql (architecture client-serveur; plus lourde) ?

Merci d'avance !

[ePoX]

La question que je me pose par rapport à tout ça, c'est de savoir si l'intégrité d'un objet peut-être garantie lorsque il est transmi par SESSION PHP.

Je n'ai personnellement jamais utilisé la session pour sauvegarder un objet, mais j'imagine d'après ce que je connais dans d'autres langages,
qu'un objet serializer en php est exactement le même lorsqu'il est deserializer.

Car dans le cas contraire, si certains paramètres de l'objet sont modifiés (modifiables),
je ne peux pas faire confiance aux "prototypes" pour effectuer les controle des saisises (de manière dynamique)...

La je ne te suit pas très bien.
Qu'est ce qui pourrait faire que ton objet soit modifié/modifiable entre le moment ou tu quittes la session et le moment ou tu la reinitialise ?
Au même titre que les types primitifs cela ne devrait pas arriver.

Autre chose, si je choisis d'utiliser une base de donnée
pour stocker les valeurs d'une session, il serait peut-être
plus pratique d'utiliser sqlite (table temporaire) plutôt
qu'une base mysql (architecture client-serveur; plus lourde) ?

C'est du pareil au même sa. Mysql propose aussi les tables temporaires il me semble.
Sa dépend surtout de ce que tu as à disposition.
SQLite est très pratique si tu n'as pas de SGBD sur l'hébergement.

Et puis sur un projet tu as 100% de chance d'être dans une archi client serveur

bbye

[Invité]

La je ne te suit pas très bien.
Qu'est ce qui pourrait faire que ton objet soit modifié/modifiable entre le moment ou tu quittes la session et le moment ou tu la reinitialise ?
Au même titre que les types primitifs cela ne devrait pas arriver.

Et bien disons qu'au niveau théorique, rien ne devrait arriver (logiquement), mais le simple fait que les variables soient converties en une chaîne de caractère, même une demi-seconde, ça implique qu'elles soient exposées en dehors de leur plage mémoire.

Par opposition, je prends par exemple un objet classique dans un langage compilé : cet objet aura sa plage mémoire reservée et verrouillée (en principe !) à toute éventualité extérieure durant toute son existence.

Ce qui me gène (et bon faut dire que je suis bien anxieux ) c'est le fait de devoir travailler avec une copie de l'objet (linéarisée - délinéarisée) et pas une référence sur lui !..

C'est du pareil au même sa. Mysql propose aussi les tables temporaires il me semble.
Sa dépend surtout de ce que tu as à disposition.
SQLite est très pratique si tu n'as pas de SGBD sur l'hébergement.

Et bien enfaite, c'est en terme de rapidité que je pensais.

Si la session est stockée dans une table (temporaire) SQLite, celle-ci devrait être accessible plus rapidement puisque la table est sur le disque dur du serveur (et donc pas d'architecture client->serveur).

Si la session est stockée dans une table (temporaire) MySQL, le schéma s'allonge : connexion au serveur -> requête -> retour du résultat au client, ceci que le serveur MySQL soit distant ou en local sur le serveur.

[wamania]

à defaut de pouvoir les transmettre, regarde du coté de __sleep() et __awake()

[Mr N.]

le simple fait que les variables soient converties en une chaîne de caractère, même une demi-seconde, ça implique qu'elles soient exposées en dehors de leur plage mémoire.

Gné ? plage mémoire ? Me serais-je trompé de forum ? Ah non on est pas sur le forum c mais bien sur le forum php... Ben alors ? Fais un peu confiance à php. Remonte à un niveau d'abstraction supérieur. Raisonne en terme de session, d'objet, mais pas en terme de "plage mémoire" !

Comme l'a dit ePox, il n'y a aucune raison que ton objet en session soit modifié. A moins d'un bug php. Et quelque soit le système de persistence que tu choisiras tu auras toujours un doute sur sa fiabilité (filesystem, db, ram, ...)

Ce qui me gène (et bon faut dire que je suis bien anxieux ) c'est le fait de devoir travailler avec une copie de l'objet (linéarisée - délinéarisée) et pas une référence sur lui !..

Ben par défaut, tout objet est détruit à la fin d'un script php. Donc oui tu ne travaillera pas sur le même objet, à la meme place mémoire que le script précédent, mais plutot sur un clône. Mise à part le fait que c'est loin d'être performant je ne vois pas ce qui peut poser problème dans cette approche.

Si la session est stockée dans une table (temporaire) MySQL, le schéma s'allonge : connexion au serveur -> requête -> retour du résultat au client, ceci que le serveur MySQL soit distant ou en local sur le serveur.

SQlite est un sgbd a par entiere. sgbd de type 'fichier' mais sgbd tout de même avec connexion/requetes.

[ePoX]

Citation:
Guardian_7 a écrit :
le simple fait que les variables soient converties en une chaîne de caractère, même une demi-seconde, ça implique qu'elles soient exposées en dehors de leur plage mémoire.

Gné ? plage mémoire ? Me serais-je trompé de forum ? Ah non on est pas sur le forum c mais bien sur le forum php... Ben alors ? Fais un peu confiance à php. Remonte à un niveau d'abstraction supérieur. Raisonne en terme de session, d'objet, mais pas en terme de "plage mémoire" !

Ce sont la des notions que je ne connait pas moi simple developpeur php Et Mr.N semble avoir été, une fois encore, de très bon conseils.

Citation:
ePoX a écrit :
C'est du pareil au même sa. Mysql propose aussi les tables temporaires il me semble.
Sa dépend surtout de ce que tu as à disposition.
SQLite est très pratique si tu n'as pas de SGBD sur l'hébergement.



Et bien enfaite, c'est en terme de rapidité que je pensais.

Si la session est stockée dans une table (temporaire) SQLite, celle-ci devrait être accessible plus rapidement puisque la table est sur le disque dur du serveur (et donc pas d'architecture client->serveur).

Si la session est stockée dans une table (temporaire) MySQL, le schéma s'allonge : connexion au serveur -> requête -> retour du résultat au client, ceci que le serveur MySQL soit distant ou en local sur le serveur.

Que se soit SQLite ou MySQL, moi tout ce qui me préoccupe dans ce schéma c'est l'utilisation de table temporaire.
Parce qu'executé une requete sur le sgbd, en local, sa prend pas des lustres.
Par contre si il faut créer la table en plus sa commence effectivement à prendre un peu de temps.
Et je ne trouve pas qu'il soit necessaire de recreer une table pour chaque session.
J'utiliserais plutot une table fixe avec de bons index pour améliorer la répidité de lecture.
Imagine que tu ais 1000 visiteurs secondes, tu vas avoir l'air fin à créer une table par utilisateur

bbye

[Invité]

Gné ? plage mémoire ? Me serais-je trompé de forum ? Ah non on est pas sur le forum c mais bien sur le forum php... Ben alors ? Fais un peu confiance à php. Remonte à un niveau d'abstraction supérieur. Raisonne en terme de session, d'objet, mais pas en terme de "plage mémoire" !

Tu as entièrement raison, je réfléchis à un niveau d'abstraction inférieur, mais c'est un peu par la force des choses (J'ai débuté avec le langage C).
Cela dit, je te remercie de me mettre au clair sur PHP et l'approche objet que j'essaie d'en faire .

Ben par défaut, tout objet est détruit à la fin d'un script php. Donc oui tu ne travaillera pas sur le même objet, à la meme place mémoire que le script précédent, mais plutot sur un clône. Mise à part le fait que c'est loin d'être performant je ne vois pas ce qui peut poser problème dans cette approche.

Qu'es-ce qui est loin d'être performant ? Le faite d'échanger des objets entre plusieurs classes sur plusieures pages, ou simplement l'approche objet en elle-même (Dont le point fort est dans la conception) ? voir les deux ?

SQlite est un sgbd a par entiere. sgbd de type 'fichier' mais sgbd tout de même avec connexion/requetes.

Oui effectivement, SQLite "émule" une SGBD, mais l'accès est sensé être plus rapide (techniquement) et plus adéquat puisqu'il y s'agit de stocker des variables linéarisées de manière temporaire (sans autre contrainte de forme).


Merci