Zend FR

sekaijin a écrit:

oui il faut convertir tous tes objet en StdClass objects et les mettre en sessions
ainsi il sont dispos durant toute la session de l'utilisateur

si tu mets des objets qui ne sont pas des StdClass en session il te faut être sur que la classe correspondante est chargée avant l'ouverture de la session

Sauf si tu sérialise tes objets, dans se cas lors de session_start() se ne sont que des chaines de caractères.

Tu peux ensuite loader la class et déséralisé ton objet.

Plus d'explication ici :
http://www.z-f.fr/forum/viewtopic.php?pid=3285#p3285

Je vais faire un petit point : toute donnée composite ( array, objet ) est systématiquement sérialisée avant d'entrer en session. la simple affectation $_SESSION['test'] = $object , appelle serialize() automatiquement dessus.
Ceci est personnalisable via php.ini.

Si la classe de l'objet contient les méthodes magiques __sleep() et __wakeup(), alors elles sont implicitement appelées  respectivement à la sérialisation, et à la désérialisation.

Zend_Db_Table_Row est prévu pour cela. A l'entrée en session, les objets sont deconnectés de la base de donnée ( grace à __sleep() ), car une connexion a une base de données est de type ressource, ce qui ne peut être sérialisé (normal).
Une fois l'objet sorti de la session, __wakeup() le marque comme non connecté. Il faudra alors spécifiquement le reconnecter à sa table ( et donc, à la base de données ) si on veut pouvoir faire intervenir la base (le sauvegarder, par exemple).

Bien entendu la classe d'un objet doit avoir été déclarée avant sa désérialisation, soit : avant un session_start(), dans le cas contraire, PHP ne sait redéfinir l'objet, et l'affecte donc à la __PHP_Incomplete_Class , l'objet garde toutes ses propriétés intactes, mais perd ses méthodes, et sa classe d'origine.
http://www.z-f.fr/forum/viewtopic.php?pid=3285#p3285 ce lien là illustre parfaitement le comportement expliqué ici.

Julien a écrit:

Bien entendu la classe d'un objet doit avoir été déclarée avant sa désérialisation, soit : avant un session_start(), dans le cas contraire, PHP ne sait redéfinir l'objet, et l'affecte donc à la __PHP_Incomplete_Class , l'objet garde toutes ses propriétés intactes, mais perd ses méthodes, et sa classe d'origine.

Je ne suis pas très pointu sur ce sujet, mais il me semble que si l'on charge la classe après un session start ça marche très bien. J'ai fait un petit test pour vérifier :

session_start();
require_once 'Zend/Db/Table/Row.php';
$articleRow = unserialize($_SESSION['article']);
echo get_class($articleRow);

Ceci m'affiche Zend_Db_Table_Row


Par contre si j'omets "require_once 'Zend/Db/Table/Row.php';", jai bien un
__PHP_Incomplete_Class

Dernière modification par 2mx (04-12-2007 09:44:43)

c'est parce que tu as sérialisé tes objet avant de les mettre en session et que le système a sérialisé la sérialisation pour sauver la session

$_SESSION['toto'] = new MyClass($data);

lorsque le script se termine $_SESSION est sérialisé et enregistré sur le disque
lorsque tu ouvre ensuite un autre script

session_start();
Zend_Db::loadClass('MyClass');
echo get_class($_SESSION['toto']);

te donne : __PHP_Incomplete_Class
par contre si tu fais

Zend_Db::loadClass('MyClass');
session_start();
echo get_class($_SESSION['toto']);

tu obtiens : MyClass

pour revenir sur mon précédent post ce qui est enregistré sur le disque dans c'est exemple est

a:1:{s:4:"toto";O:7:"MyClass":1:{s:1:"a";i:45;}}

a: la session est un tableau
1: qui contient 1 élément
{s:4"toto"; dont la clef est la chaine (s: ) de longueur 4 (4: ) et de valeur toto
O: et le contenu un objet
7: don la classe à un nom sur 7 caractère
"MyClass": de nom MyClass
1: qui a un membre
{s:1:"a"; dont le nom est une chaine de 1 caractère de valeur a
i:45; et dont la valeur est un entier (i: ) de valeur 45

pour retrouver le nom de la classe il faut repérer ;O:7:"MyClass": pour pouvoir la charger avant
sinon il faut être sur que tu charge bien toutes les classe possible.

preg_match_all('|;O:[0-9]+:"([^"]+)":|', $serializedData, $matches);

$matches[1] contient alors le tableau de toute les classes présentes dans la session (attention au doublon)

ta solution consiste à sérialiser une première fois l'objet (qui est donc inexploitable dans la session) pour placer la chaîne dans la session et la retirer pour reconstruire l'objet
ainsi :

a:1:{s:4:"toto";s:31:"O:7:"myclass":1:{s:1:"a";i:45;}";}

ce coup ci dans la saision nous avons toujours 1 élément a:1:{s:4:"toto"; qui ce coup ci est une chaine
s:31:"..........";}
il est donc impossible ni dans le premier script ni dans le second de faire

$_SESSION['toto'] = new MyClass($data);
$_SESSION['toto']->getMyName();

ou dans le second

$_SESSION['toto']->getMyName();

mais effectivement ça supprime les __PHP_Incomplete_Class puisque tu ne mets jamais d'objet dans la session.

A+JYT

Dernière modification par sekaijin (04-12-2007 10:30:34)

Julien a écrit:

Normal : tu sérialises à la main. ... Je répète qu'il n'est pas nécéssaire de sérialiser à la main, avant le passage en session...

Oui, je suis d'accord, ce que je voulais dire, c'est que l'on est pas obligé de charger les classes avant session_start(), surtout si l'on  utilise MVC et que le session_start() est dans le bootstrap.

Donc si l'on veut éviter de charger les classes avant session_start(), et si j'ai bien tout compris, on a 2 solutions :

* On sérialise à la main avec dans l'idéale une class qui implémente l'interface serializable
* On utilise la technique de sekaijin avec la StdClass et des classes qui implémente toStdClass() et setFromStdClass() ce qui nous évite de sérialisé à la main.

Dernière modification par 2mx (04-12-2007 11:35:40)

Est il pertinent de mettre beaucoup de chose en session ? sur quoi cela influe les perfs si j'abuse des sessions genre que je mets des dizaines de gros objets dedans, multiplié par des dizaines d'utilisateurs connectés quel risque je prends à faire cela ?