final public static function getInstance() {
if (!IsSet(self::$instance)) {
error_log('initialisation du singleton');
self::$instance = new TypesTruc ();
}
return self::$instance;
}
public function getTypes(){
return $this->types;
}
}
Non. Lors de plusieurs appels dans la même page. Pour le problème de persistance d'un objet entre différents appels, les réponses ont été données par ailleurs.
Il n'y a pas (à ma connaissance) de serveur d'application php comme tu peux en connaître dans le monde Java.
@+ Ok, je fais maintenant bien le distinguo entre un serveur d'application
et l'environnement d'exécution de php Olivier
Non. Lors de plusieurs appels dans la même page. Pour le problème de
persistance d'un objet entre différents appels, les réponses ont été
données par ailleurs.
Il n'y a pas (à ma connaissance) de serveur d'application php comme tu peux
en connaître dans le monde Java.
@+
Ok, je fais maintenant bien le distinguo entre un serveur d'application
Non. Lors de plusieurs appels dans la même page. Pour le problème de persistance d'un objet entre différents appels, les réponses ont été données par ailleurs.
Il n'y a pas (à ma connaissance) de serveur d'application php comme tu peux en connaître dans le monde Java.
@+ Ok, je fais maintenant bien le distinguo entre un serveur d'application
et l'environnement d'exécution de php Olivier
ownowl
par contre ces variables ne seront pas dispo à vie comme sur ton serveur d'app..
tiens, j'ai trouvé ça : http://linuxfr.org/forums/21/8544.html
Si tu veux de la persistance de données entre deux appels de scripts, tu dois utiliser un fichier ou une base de données.
Effectivement la mémoire partagée via IPC peut être une solution pour les singletons
éventuellement, une solution pour cacher des pages serait d'utiliser un link mémoire sur un disque physique :
Ou encore les variables de session Et à ton avis, elles sont stockées comment, ces variables ?
ca ne serait pas sur le disque, par hasard ?
Si, dans des fichiers textes situés dans le repertoire temporaires : )))
C'est d'ailleurs l'occasion de bien rappeller de ne JAMAIS rendre accessible en ligne ce repertoire temporaire, justement pour cette raison principale. : )
Stef
Ou encore les variables de session
Et à ton avis, elles sont stockées comment, ces variables ?
ca ne serait pas sur le disque, par hasard ?
Si, dans des fichiers textes situés dans le repertoire temporaires : )))
C'est d'ailleurs l'occasion de bien rappeller de ne JAMAIS rendre accessible
en ligne ce repertoire temporaire, justement pour cette raison principale.
: )
Ou encore les variables de session Et à ton avis, elles sont stockées comment, ces variables ?
ca ne serait pas sur le disque, par hasard ?
Si, dans des fichiers textes situés dans le repertoire temporaires : )))
C'est d'ailleurs l'occasion de bien rappeller de ne JAMAIS rendre accessible en ligne ce repertoire temporaire, justement pour cette raison principale. : )
Stef
Jibux
Ou encore les variables de session
Et à ton avis, elles sont stockées comment, ces variables ?
Dans des fichiers (mais sous *nix tout est fichier) qui sont stockés à l'endroit défini par session.save_path. Donc, on pourrait très bien imaginer changer le chemin par défaut vers un ram-disk par exemple. Mais je reconnais qu'il s'agit là d'un cas très particulier.
Ou encore les variables de session
Et à ton avis, elles sont stockées comment, ces variables ?
Dans des fichiers (mais sous *nix tout est fichier) qui sont stockés à
l'endroit défini par session.save_path.
Donc, on pourrait très bien imaginer changer le chemin par défaut vers
un ram-disk par exemple.
Mais je reconnais qu'il s'agit là d'un cas très particulier.
Et à ton avis, elles sont stockées comment, ces variables ?
Dans des fichiers (mais sous *nix tout est fichier) qui sont stockés à l'endroit défini par session.save_path. Donc, on pourrait très bien imaginer changer le chemin par défaut vers un ram-disk par exemple. Mais je reconnais qu'il s'agit là d'un cas très particulier.
Bruno Desthuilliers
(snip)
c'est pourtant le but de ce design pattern. La gestion d'un service/objet commun à l'ensemble des requêtes utilisateur.
La solution est simple: un autre process serveur fourni le service.
effectivement, mais ca nessécite de mettre en place un protocole de communication (soap ou autre), n'est ce pas ?
Ca me semble assez difficilement contournable, en effet.
(snip)
c'est pourtant le but de ce design pattern. La gestion d'un
service/objet commun à l'ensemble des requêtes utilisateur.
La solution est simple: un autre process serveur fourni le service.
effectivement, mais ca nessécite de mettre en place un protocole de
communication (soap ou autre), n'est ce pas ?
Ca me semble assez difficilement contournable, en effet.
