De la même manière qu'il y a le contexte de requette et le contexte de
session, je voudrais savoir s'il existe un contexte d'application. Et si
oui comment on s'en sert.
Merci bcp.
Th.
PS : J'utilise des mots Java mais je suis certain que tout le monde aura
compris.
De la même manière qu'il y a le contexte de requette $_REQUEST
et le contexte de
session, $_SESSION
je voudrais savoir s'il existe un contexte d'application. $GLOBALS ?
Et si oui comment on s'en sert.
A un détail près (il est accessible partout sans devoir le déclarer global), ce n'est jamais qu'un tableau associatif...
Ceci étant, je ne sais pas dans quelle mesure ça correspond à ce que tu peux connaître en Java...
HTH -- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
ftc
je voudrais savoir s'il existe un contexte d'application. $GLOBALS ?
Je pense plutôt que Thierry parlait de variables que l'on peut partager entre les scripts pour n'importe quel visiteur.
En java, lorsqu'on déclare qu'une instance d'un objet a un "scope" application, la même instance de l'objet est partagée pour tout le monde pendant la durée de vie de cette application.
PHP ne dispose pas de ce genre de fonctionalité, ce n'est pas à proprement parler un serveur applicatif. Les scripts sont rechargés à chaque exécution contrairement aux servlet et jsp ou le serveur se charge de stocker l'état d'un objet s'il doit être déchargé de la mémoire.
Si on veut un contexte de type application, il faut le gérer soit même.
je voudrais savoir s'il existe un contexte d'application.
$GLOBALS ?
Je pense plutôt que Thierry parlait de variables que l'on peut partager
entre les scripts pour n'importe quel visiteur.
En java, lorsqu'on déclare qu'une instance d'un objet a un "scope"
application, la même instance de l'objet est partagée pour tout le monde
pendant la durée de vie de cette application.
PHP ne dispose pas de ce genre de fonctionalité, ce n'est pas à
proprement parler un serveur applicatif. Les scripts sont rechargés à
chaque exécution contrairement aux servlet et jsp ou le serveur se
charge de stocker l'état d'un objet s'il doit être déchargé de la mémoire.
Si on veut un contexte de type application, il faut le gérer soit même.
je voudrais savoir s'il existe un contexte d'application. $GLOBALS ?
Je pense plutôt que Thierry parlait de variables que l'on peut partager entre les scripts pour n'importe quel visiteur.
En java, lorsqu'on déclare qu'une instance d'un objet a un "scope" application, la même instance de l'objet est partagée pour tout le monde pendant la durée de vie de cette application.
PHP ne dispose pas de ce genre de fonctionalité, ce n'est pas à proprement parler un serveur applicatif. Les scripts sont rechargés à chaque exécution contrairement aux servlet et jsp ou le serveur se charge de stocker l'état d'un objet s'il doit être déchargé de la mémoire.
Si on veut un contexte de type application, il faut le gérer soit même.
loufoque
Thierry a dit le 03/07/2005 à 13:11:
De la même manière qu'il y a le contexte de requette et le contexte de session, je voudrais savoir s'il existe un contexte d'application. Et si oui comment on s'en sert.
On vient d'en parler dans le sujet "Comment conserver une valeur entre differentes pages sans liens entre elles".
Il y a la solution mémoire partagée posix ou alors faire tourner un démon qui stockerait les variables dans son espace mémoire à lui et qui les modifie/donne à la demande.
Thierry a dit le 03/07/2005 à 13:11:
De la même manière qu'il y a le contexte de requette et le contexte de
session, je voudrais savoir s'il existe un contexte d'application. Et si
oui comment on s'en sert.
On vient d'en parler dans le sujet "Comment conserver une valeur entre
differentes pages sans liens entre elles".
Il y a la solution mémoire partagée posix ou alors faire tourner un
démon qui stockerait les variables dans son espace mémoire à lui et qui
les modifie/donne à la demande.
De la même manière qu'il y a le contexte de requette et le contexte de session, je voudrais savoir s'il existe un contexte d'application. Et si oui comment on s'en sert.
On vient d'en parler dans le sujet "Comment conserver une valeur entre differentes pages sans liens entre elles".
Il y a la solution mémoire partagée posix ou alors faire tourner un démon qui stockerait les variables dans son espace mémoire à lui et qui les modifie/donne à la demande.
Thierry
je voudrais savoir s'il existe un contexte d'application. $GLOBALS ?
Je pense plutôt que Thierry parlait de variables que l'on peut partager entre les scripts pour n'importe quel visiteur.
En java, lorsqu'on déclare qu'une instance d'un objet a un "scope" application, la même instance de l'objet est partagée pour tout le monde pendant la durée de vie de cette application.
PHP ne dispose pas de ce genre de fonctionalité, ce n'est pas à proprement parler un serveur applicatif. Les scripts sont rechargés à chaque exécution contrairement aux servlet et jsp ou le serveur se charge de stocker l'état d'un objet s'il doit être déchargé de la mémoire.
Si on veut un contexte de type application, il faut le gérer soit même.
Ce qui m'interesse, c'est de stoquer une variable en memoire une seule fois. Elle doit etre accessible par tous les utilisateurs, et nons pas à partir d'une seule session. Est ce que $GLOBALS fait ça ? En gros je stoque des données sous forme d'arbre. Ces données sont issues de xml et de mysql. C'est assez long à charger. Or ca ne change jamais... Pour l'instant je stoque en session, mais chaque utilisateur doit donc les recharger pour rien...
Titi
je voudrais savoir s'il existe un contexte d'application.
$GLOBALS ?
Je pense plutôt que Thierry parlait de variables que l'on peut partager
entre les scripts pour n'importe quel visiteur.
En java, lorsqu'on déclare qu'une instance d'un objet a un "scope"
application, la même instance de l'objet est partagée pour tout le monde
pendant la durée de vie de cette application.
PHP ne dispose pas de ce genre de fonctionalité, ce n'est pas à
proprement parler un serveur applicatif. Les scripts sont rechargés à
chaque exécution contrairement aux servlet et jsp ou le serveur se
charge de stocker l'état d'un objet s'il doit être déchargé de la mémoire.
Si on veut un contexte de type application, il faut le gérer soit même.
Ce qui m'interesse, c'est de stoquer une variable en memoire une seule
fois. Elle doit etre accessible par tous les utilisateurs, et nons pas à
partir d'une seule session. Est ce que $GLOBALS fait ça ?
En gros je stoque des données sous forme d'arbre. Ces données sont
issues de xml et de mysql. C'est assez long à charger. Or ca ne change
jamais... Pour l'instant je stoque en session, mais chaque utilisateur
doit donc les recharger pour rien...
je voudrais savoir s'il existe un contexte d'application. $GLOBALS ?
Je pense plutôt que Thierry parlait de variables que l'on peut partager entre les scripts pour n'importe quel visiteur.
En java, lorsqu'on déclare qu'une instance d'un objet a un "scope" application, la même instance de l'objet est partagée pour tout le monde pendant la durée de vie de cette application.
PHP ne dispose pas de ce genre de fonctionalité, ce n'est pas à proprement parler un serveur applicatif. Les scripts sont rechargés à chaque exécution contrairement aux servlet et jsp ou le serveur se charge de stocker l'état d'un objet s'il doit être déchargé de la mémoire.
Si on veut un contexte de type application, il faut le gérer soit même.
Ce qui m'interesse, c'est de stoquer une variable en memoire une seule fois. Elle doit etre accessible par tous les utilisateurs, et nons pas à partir d'une seule session. Est ce que $GLOBALS fait ça ? En gros je stoque des données sous forme d'arbre. Ces données sont issues de xml et de mysql. C'est assez long à charger. Or ca ne change jamais... Pour l'instant je stoque en session, mais chaque utilisateur doit donc les recharger pour rien...
Titi
ftc
Ce qui m'interesse, c'est de stoquer une variable en memoire une seule fois. Elle doit etre accessible par tous les utilisateurs, et nons pas à partir d'une seule session. Est ce que $GLOBALS fait ça ?
Non, $GLOBALS ne fait pas cela, $GLOBALS est un tableau représentant les variables globales à un script.
La solution est de stocker de façon sérialisée dans un fichier ou en mémoire partagée les variables. ( http://fr.php.net/manual/fr/ref.sem.php )
Ce qui m'interesse, c'est de stoquer une variable en memoire une seule
fois. Elle doit etre accessible par tous les utilisateurs, et nons pas à
partir d'une seule session. Est ce que $GLOBALS fait ça ?
Non, $GLOBALS ne fait pas cela, $GLOBALS est un tableau représentant les
variables globales à un script.
La solution est de stocker de façon sérialisée dans un fichier ou en
mémoire partagée les variables. ( http://fr.php.net/manual/fr/ref.sem.php )
Ce qui m'interesse, c'est de stoquer une variable en memoire une seule fois. Elle doit etre accessible par tous les utilisateurs, et nons pas à partir d'une seule session. Est ce que $GLOBALS fait ça ?
Non, $GLOBALS ne fait pas cela, $GLOBALS est un tableau représentant les variables globales à un script.
La solution est de stocker de façon sérialisée dans un fichier ou en mémoire partagée les variables. ( http://fr.php.net/manual/fr/ref.sem.php )
Guillaume Bouchard
ftc wrote:
La solution est de stocker de façon sérialisée dans un fichier ou en mémoire partagée les variables. ( http://fr.php.net/manual/fr/ref.sem.php )
Attention, extension non disponible sur certaines platoformes.
Maitenant la question à se poser c'est ? L'acces disque de lecture (et éventuellement de deserialisation) est-t-il si lent qu'il faille tant se prendre la tête ?
Moi je dis que base de donnée ou fichier, c'est déjà bien. (Après chaques problèmatique est differentes...)
-- Guillaume.
ftc wrote:
La solution est de stocker de façon sérialisée dans un fichier ou en
mémoire partagée les variables. ( http://fr.php.net/manual/fr/ref.sem.php )
Attention, extension non disponible sur certaines platoformes.
Maitenant la question à se poser c'est ? L'acces disque de lecture (et
éventuellement de deserialisation) est-t-il si lent qu'il faille tant se
prendre la tête ?
Moi je dis que base de donnée ou fichier, c'est déjà bien. (Après
chaques problèmatique est differentes...)
La solution est de stocker de façon sérialisée dans un fichier ou en mémoire partagée les variables. ( http://fr.php.net/manual/fr/ref.sem.php )
Attention, extension non disponible sur certaines platoformes.
Maitenant la question à se poser c'est ? L'acces disque de lecture (et éventuellement de deserialisation) est-t-il si lent qu'il faille tant se prendre la tête ?
Moi je dis que base de donnée ou fichier, c'est déjà bien. (Après chaques problèmatique est differentes...)
-- Guillaume.
ftc
ftc wrote:
La solution est de stocker de façon sérialisée dans un fichier ou en mémoire partagée les variables. ( http://fr.php.net/manual/fr/ref.sem.php )
Attention, extension non disponible sur certaines platoformes.
Oui, j'avais oublié de précisé.
Maitenant la question à se poser c'est ? L'acces disque de lecture (et éventuellement de deserialisation) est-t-il si lent qu'il faille tant se prendre la tête ?
Vu qu'il ne semble pas y avoir de mise à jour, c'est vrai que de traiter avec un fichier est plus simple. S'il y a des mises à jour à faire, autant utiliser la mémoire partagée, ce n'est pas plus complexe et c'est quand même plus rapide.
J'en profite pour lancer une petite question sur le lock de fichiers en PHP. J'utilise toujours flock lorsque je doit écrire dans un fichier, cependant il semble ( d'après la doc ) qu'il n'y en ait besoin que sous Windows. Quelqu'un aurait des infos ?
ftc wrote:
La solution est de stocker de façon sérialisée dans un fichier ou en
mémoire partagée les variables. (
http://fr.php.net/manual/fr/ref.sem.php )
Attention, extension non disponible sur certaines platoformes.
Oui, j'avais oublié de précisé.
Maitenant la question à se poser c'est ? L'acces disque de lecture (et
éventuellement de deserialisation) est-t-il si lent qu'il faille tant se
prendre la tête ?
Vu qu'il ne semble pas y avoir de mise à jour, c'est vrai que de traiter
avec un fichier est plus simple. S'il y a des mises à jour à faire,
autant utiliser la mémoire partagée, ce n'est pas plus complexe et c'est
quand même plus rapide.
J'en profite pour lancer une petite question sur le lock de fichiers en
PHP. J'utilise toujours flock lorsque je doit écrire dans un fichier,
cependant il semble ( d'après la doc ) qu'il n'y en ait besoin que sous
Windows. Quelqu'un aurait des infos ?
La solution est de stocker de façon sérialisée dans un fichier ou en mémoire partagée les variables. ( http://fr.php.net/manual/fr/ref.sem.php )
Attention, extension non disponible sur certaines platoformes.
Oui, j'avais oublié de précisé.
Maitenant la question à se poser c'est ? L'acces disque de lecture (et éventuellement de deserialisation) est-t-il si lent qu'il faille tant se prendre la tête ?
Vu qu'il ne semble pas y avoir de mise à jour, c'est vrai que de traiter avec un fichier est plus simple. S'il y a des mises à jour à faire, autant utiliser la mémoire partagée, ce n'est pas plus complexe et c'est quand même plus rapide.
J'en profite pour lancer une petite question sur le lock de fichiers en PHP. J'utilise toujours flock lorsque je doit écrire dans un fichier, cependant il semble ( d'après la doc ) qu'il n'y en ait besoin que sous Windows. Quelqu'un aurait des infos ?
loufoque
Guillaume Bouchard a dit le 05/07/2005 à 02:29:
Maitenant la question à se poser c'est ? L'acces disque de lecture (et éventuellement de deserialisation) est-t-il si lent qu'il faille tant se prendre la tête ?
La meilleure alternative c'est de faire tourner un démon, ce que fait d'ailleurs cygwin pour émuler la mémoire partagée. Après il faut pouvoir lancer ce démon.
Guillaume Bouchard a dit le 05/07/2005 à 02:29:
Maitenant la question à se poser c'est ? L'acces disque de lecture (et
éventuellement de deserialisation) est-t-il si lent qu'il faille tant se
prendre la tête ?
La meilleure alternative c'est de faire tourner un démon, ce que fait
d'ailleurs cygwin pour émuler la mémoire partagée.
Après il faut pouvoir lancer ce démon.
Maitenant la question à se poser c'est ? L'acces disque de lecture (et éventuellement de deserialisation) est-t-il si lent qu'il faille tant se prendre la tête ?
La meilleure alternative c'est de faire tourner un démon, ce que fait d'ailleurs cygwin pour émuler la mémoire partagée. Après il faut pouvoir lancer ce démon.
FightClub!
Maitenant la question à se poser c'est ? L'acces disque de lecture (et éventuellement de deserialisation) est-t-il si lent qu'il faille tant se prendre la tête ?
Vu qu'il ne semble pas y avoir de mise à jour, c'est vrai que de traiter avec un fichier est plus simple. S'il y a des mises à jour à faire, autant utiliser la mémoire partagée, ce n'est pas plus complexe et c'est quand même plus rapide.
Il y a aussi les tables de type HEAP du coté de MySQL, qui réconcilient l'accès rapide et le structurel d'une base de données Mais tout dépend du volume de données à traiter, car la RAM est limitée aussi :)
--
http://SurveilleTonSite.sd2i.org Alerte gratuite par mail en cas de problème sur votre site.
Maitenant la question à se poser c'est ? L'acces disque de lecture (et
éventuellement de deserialisation) est-t-il si lent qu'il faille tant
se prendre la tête ?
Vu qu'il ne semble pas y avoir de mise à jour, c'est vrai que de traiter
avec un fichier est plus simple. S'il y a des mises à jour à faire,
autant utiliser la mémoire partagée, ce n'est pas plus complexe et c'est
quand même plus rapide.
Il y a aussi les tables de type HEAP du coté de MySQL, qui réconcilient
l'accès rapide et le structurel d'une base de données
Mais tout dépend du volume de données à traiter, car la RAM est limitée
aussi :)
--
http://SurveilleTonSite.sd2i.org
Alerte gratuite par mail en cas de problème sur votre site.
Maitenant la question à se poser c'est ? L'acces disque de lecture (et éventuellement de deserialisation) est-t-il si lent qu'il faille tant se prendre la tête ?
Vu qu'il ne semble pas y avoir de mise à jour, c'est vrai que de traiter avec un fichier est plus simple. S'il y a des mises à jour à faire, autant utiliser la mémoire partagée, ce n'est pas plus complexe et c'est quand même plus rapide.
Il y a aussi les tables de type HEAP du coté de MySQL, qui réconcilient l'accès rapide et le structurel d'une base de données Mais tout dépend du volume de données à traiter, car la RAM est limitée aussi :)
--
http://SurveilleTonSite.sd2i.org Alerte gratuite par mail en cas de problème sur votre site.
