Je suis débutant et me lance dans mon 2eme petit site (le 1er était une
simple galerie d'images). J'ai le cas de documents (listes) que plusieurs
personnes doivent pouvoir mettre à jour. La solution que je pense mettre en
oeuvre est de faire une table SQL avec les titres des listes et un champs
"utilisé" qui est à 0 par défaut, si quelqu'un clique sur le lien menant à
cette page, test, si 0 le passe à 1 et va sur la bonne page, si 1 redirige
vers une autre page "document en cours d'utilisation" (qui elle même
vérifie la page régulièrement pour avertir quand elle est libre) et repasse
à 0 quand cette personne quitte la page pour que quelqu'un d'autre puisse y
acceder.
Ce qui me pose souci, c'est le nombre de requetes SQL. Dans le bouquin que
j'ai acheté (Micro-Application) on insiste bien sur le fait que ce qui est
lourd et lent, ce sont les requetes SQL. Est-ce qu'un petit fichier faisant
office de "cookie" serveur ferait un systeme plus léger (je pensais à
"fopen" et consorts)?
C'est peut-etre du pinnaillage vu la taille du site et sa fréquentation
prévue mais je suis en train d'apprendre, je me pose plein de questions ;o)
merci
oragoun
--
oragoun_b_nospam_@yahoo.fr
Effacez "_nospam_" si vous desirez me repondre en prive
Delete "_nospam_" for private answer
Le "Reply To" est valide
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sebastien
et repasse
à 0 quand cette personne quitte la page pour que quelqu'un d'autre puisse y acceder.
Et si la personne ferme son navigateur sans changer de page ?
Ce qui me pose souci, c'est le nombre de requetes SQL. Dans le bouquin que j'ai acheté (Micro-Application) on insiste bien sur le fait que ce qui est lourd et lent, ce sont les requetes SQL. Est-ce qu'un petit fichier faisant office de "cookie" serveur ferait un systeme plus léger (je pensais à "fopen" et consorts)?
Effectivement, les requêtes SQL sont un goulot d'étranglement, mais du moment que ta BdD est bien pensée et correctement optimisée (voir article sur www.phpinfo.net) tu peux en faire sans souci plus d'une dizaine par page, d'ailleurs des CMS comme phpNuke en font facilement une cinquantaine (évite de suivre cet exemple). De plus ton nouveau site a l'air d'avoir besoin d'un certain dynamisme qu'un système de cache ne pourrait pas te fournir.
C'est peut-etre du pinnaillage vu la taille du site et sa fréquentation prévue mais je suis en train d'apprendre, je me pose plein de questions ;o)
Un exemple intéressant de cache SQL : afficher une page d'accueil (qui doit être la plus rapide d'un site) les 10 dernières discussions du forum. Le cache serait remis à jour toutes les 5 minutes. S'il y a décalage avec la réalité ce n'est pas grave, ce n'est qu'un forum, alors que dans ton cas le travail d'un utilisateur risque d'être perdu. À utiliser ou non selon les cas.
et repasse
à 0 quand cette personne quitte la page pour que quelqu'un d'autre puisse y
acceder.
Et si la personne ferme son navigateur sans changer de page ?
Ce qui me pose souci, c'est le nombre de requetes SQL. Dans le bouquin que
j'ai acheté (Micro-Application) on insiste bien sur le fait que ce qui est
lourd et lent, ce sont les requetes SQL. Est-ce qu'un petit fichier faisant
office de "cookie" serveur ferait un systeme plus léger (je pensais à
"fopen" et consorts)?
Effectivement, les requêtes SQL sont un goulot d'étranglement, mais du
moment que ta BdD est bien pensée et correctement optimisée (voir
article sur www.phpinfo.net) tu peux en faire sans souci plus d'une
dizaine par page, d'ailleurs des CMS comme phpNuke en font facilement
une cinquantaine (évite de suivre cet exemple).
De plus ton nouveau site a l'air d'avoir besoin d'un certain dynamisme
qu'un système de cache ne pourrait pas te fournir.
C'est peut-etre du pinnaillage vu la taille du site et sa fréquentation
prévue mais je suis en train d'apprendre, je me pose plein de questions ;o)
Un exemple intéressant de cache SQL : afficher une page d'accueil (qui
doit être la plus rapide d'un site) les 10 dernières discussions du
forum. Le cache serait remis à jour toutes les 5 minutes.
S'il y a décalage avec la réalité ce n'est pas grave, ce n'est qu'un
forum, alors que dans ton cas le travail d'un utilisateur risque d'être
perdu.
À utiliser ou non selon les cas.
à 0 quand cette personne quitte la page pour que quelqu'un d'autre puisse y acceder.
Et si la personne ferme son navigateur sans changer de page ?
Ce qui me pose souci, c'est le nombre de requetes SQL. Dans le bouquin que j'ai acheté (Micro-Application) on insiste bien sur le fait que ce qui est lourd et lent, ce sont les requetes SQL. Est-ce qu'un petit fichier faisant office de "cookie" serveur ferait un systeme plus léger (je pensais à "fopen" et consorts)?
Effectivement, les requêtes SQL sont un goulot d'étranglement, mais du moment que ta BdD est bien pensée et correctement optimisée (voir article sur www.phpinfo.net) tu peux en faire sans souci plus d'une dizaine par page, d'ailleurs des CMS comme phpNuke en font facilement une cinquantaine (évite de suivre cet exemple). De plus ton nouveau site a l'air d'avoir besoin d'un certain dynamisme qu'un système de cache ne pourrait pas te fournir.
C'est peut-etre du pinnaillage vu la taille du site et sa fréquentation prévue mais je suis en train d'apprendre, je me pose plein de questions ;o)
Un exemple intéressant de cache SQL : afficher une page d'accueil (qui doit être la plus rapide d'un site) les 10 dernières discussions du forum. Le cache serait remis à jour toutes les 5 minutes. S'il y a décalage avec la réalité ce n'est pas grave, ce n'est qu'un forum, alors que dans ton cas le travail d'un utilisateur risque d'être perdu. À utiliser ou non selon les cas.
Guillaume BOUCHARD
oragoun wrote:
Bonjour,
Bonjour.
J'ai le cas de documents (listes) que plusieurs personnes doivent pouvoir mettre à jour.
Comment sont stocké ces documents ?
La solution que je pense mettre en oeuvre est de faire une table SQL avec les titres des listes et un champs "utilisé" qui est à 0 par défaut, si quelqu'un clique sur le lien menant à cette page, test, si 0 le passe à 1 et va sur la bonne page, si 1 redirige vers une autre page "document en cours d'utilisation" (qui elle même vérifie la page régulièrement pour avertir quand elle est libre) et repasse à 0 quand cette personne quitte la page pour que quelqu'un d'autre puisse y acceder.
Et n'oublie pas un systeme d'expiration de session de modification pour éviter que quelqu'un qui (plante, ferme son navigateur, oublie sa fenetre) ne bloque le document pendant un temps trop long voir illimité... Et betonne bien le concept, parce qu'il n'est pas rare qu'un "verrou" de ce style reste activé. (ma derniere experience date de 2 jours où un prog ne se lancait plus à cause d'un fichier lock qui etait resté.)
Ce qui me pose souci, c'est le nombre de requetes SQL. Dans le bouquin que j'ai acheté (Micro-Application) on insiste bien sur le fait que ce qui est lourd et lent, ce sont les requetes SQL. Est-ce qu'un petit fichier faisant office de "cookie" serveur ferait un systeme plus léger (je pensais à "fopen" et consorts)?
Pourquoi pas.
C'est peut-etre du pinnaillage vu la taille du site et sa fréquentation prévue mais je suis en train d'apprendre, je me pose plein de questions ;o)
Tu as bien raisons, il vaux mieux prevenir que guerir comme disait ma grand-mere...
Maitenant, je ne pense pas en pratique qu'il faut faire un systeme de "refresh" automatique. Cela consomme une bonne quantité de ressources pour un interet limité. Si la personne veux rafraichir la page, elle le fait, soit elle va faire un tour et reviens quelques temps après.
Maitenant tu peux aussi esseyer une autre approche. Tu stockes avec un doc la date de sa dernière mise à jour. Lors de la tentative de modifications, dans le cas où la date n'est plus la meme, tu ne fais rien et avertit l'utilisateur que le fichier à changer en lui soumettant eventuellement le nouveau contenu pour qu'il voie les modifications.
Cette technique n'est pas optimale non plus. Maitenant, ce genre de chose me fais penser au concept de wiki. Esseye de voir comment les "grands" scripts de wiki gerent ce problème et tu aura sans doute une reponse plus adapté.
En esperant que ma reponse servira à quelque chose.
-- Guillaume.
oragoun wrote:
Bonjour,
Bonjour.
J'ai le cas de documents (listes) que plusieurs
personnes doivent pouvoir mettre à jour.
Comment sont stocké ces documents ?
La solution que je pense mettre en
oeuvre est de faire une table SQL avec les titres des listes et un champs
"utilisé" qui est à 0 par défaut, si quelqu'un clique sur le lien menant à
cette page, test, si 0 le passe à 1 et va sur la bonne page, si 1 redirige
vers une autre page "document en cours d'utilisation" (qui elle même
vérifie la page régulièrement pour avertir quand elle est libre) et repasse
à 0 quand cette personne quitte la page pour que quelqu'un d'autre puisse y
acceder.
Et n'oublie pas un systeme d'expiration de session de modification pour
éviter que quelqu'un qui (plante, ferme son navigateur, oublie sa
fenetre) ne bloque le document pendant un temps trop long voir
illimité... Et betonne bien le concept, parce qu'il n'est pas rare qu'un
"verrou" de ce style reste activé. (ma derniere experience date de 2
jours où un prog ne se lancait plus à cause d'un fichier lock qui etait
resté.)
Ce qui me pose souci, c'est le nombre de requetes SQL. Dans le bouquin que
j'ai acheté (Micro-Application) on insiste bien sur le fait que ce qui est
lourd et lent, ce sont les requetes SQL. Est-ce qu'un petit fichier faisant
office de "cookie" serveur ferait un systeme plus léger (je pensais à
"fopen" et consorts)?
Pourquoi pas.
C'est peut-etre du pinnaillage vu la taille du site et sa fréquentation
prévue mais je suis en train d'apprendre, je me pose plein de questions ;o)
Tu as bien raisons, il vaux mieux prevenir que guerir comme disait ma
grand-mere...
Maitenant, je ne pense pas en pratique qu'il faut faire un systeme de
"refresh" automatique. Cela consomme une bonne quantité de ressources
pour un interet limité. Si la personne veux rafraichir la page, elle le
fait, soit elle va faire un tour et reviens quelques temps après.
Maitenant tu peux aussi esseyer une autre approche. Tu stockes avec un
doc la date de sa dernière mise à jour. Lors de la tentative de
modifications, dans le cas où la date n'est plus la meme, tu ne fais
rien et avertit l'utilisateur que le fichier à changer en lui soumettant
eventuellement le nouveau contenu pour qu'il voie les modifications.
Cette technique n'est pas optimale non plus.
Maitenant, ce genre de chose me fais penser au concept de wiki. Esseye
de voir comment les "grands" scripts de wiki gerent ce problème et tu
aura sans doute une reponse plus adapté.
En esperant que ma reponse servira à quelque chose.
J'ai le cas de documents (listes) que plusieurs personnes doivent pouvoir mettre à jour.
Comment sont stocké ces documents ?
La solution que je pense mettre en oeuvre est de faire une table SQL avec les titres des listes et un champs "utilisé" qui est à 0 par défaut, si quelqu'un clique sur le lien menant à cette page, test, si 0 le passe à 1 et va sur la bonne page, si 1 redirige vers une autre page "document en cours d'utilisation" (qui elle même vérifie la page régulièrement pour avertir quand elle est libre) et repasse à 0 quand cette personne quitte la page pour que quelqu'un d'autre puisse y acceder.
Et n'oublie pas un systeme d'expiration de session de modification pour éviter que quelqu'un qui (plante, ferme son navigateur, oublie sa fenetre) ne bloque le document pendant un temps trop long voir illimité... Et betonne bien le concept, parce qu'il n'est pas rare qu'un "verrou" de ce style reste activé. (ma derniere experience date de 2 jours où un prog ne se lancait plus à cause d'un fichier lock qui etait resté.)
Ce qui me pose souci, c'est le nombre de requetes SQL. Dans le bouquin que j'ai acheté (Micro-Application) on insiste bien sur le fait que ce qui est lourd et lent, ce sont les requetes SQL. Est-ce qu'un petit fichier faisant office de "cookie" serveur ferait un systeme plus léger (je pensais à "fopen" et consorts)?
Pourquoi pas.
C'est peut-etre du pinnaillage vu la taille du site et sa fréquentation prévue mais je suis en train d'apprendre, je me pose plein de questions ;o)
Tu as bien raisons, il vaux mieux prevenir que guerir comme disait ma grand-mere...
Maitenant, je ne pense pas en pratique qu'il faut faire un systeme de "refresh" automatique. Cela consomme une bonne quantité de ressources pour un interet limité. Si la personne veux rafraichir la page, elle le fait, soit elle va faire un tour et reviens quelques temps après.
Maitenant tu peux aussi esseyer une autre approche. Tu stockes avec un doc la date de sa dernière mise à jour. Lors de la tentative de modifications, dans le cas où la date n'est plus la meme, tu ne fais rien et avertit l'utilisateur que le fichier à changer en lui soumettant eventuellement le nouveau contenu pour qu'il voie les modifications.
Cette technique n'est pas optimale non plus. Maitenant, ce genre de chose me fais penser au concept de wiki. Esseye de voir comment les "grands" scripts de wiki gerent ce problème et tu aura sans doute une reponse plus adapté.
En esperant que ma reponse servira à quelque chose.
-- Guillaume.
Paul Monteiro
Il faut t'orienter vers les requêtes car : - j'ai l'impréssion que les requêtes pour ton cas ne sont pas lourdes du tout - c'est plus sur car les infos sont centralisés et donc pas de confusion possible pour savoir si le document est ouvert ou pas! en effet imagine que tu es un problème sur le poste local (plantage, etc..) le cookie ne serait pas mis à jour....
@+
--
Il faut t'orienter vers les requêtes car :
- j'ai l'impréssion que les requêtes pour ton cas ne sont pas lourdes du
tout
- c'est plus sur car les infos sont centralisés et donc pas de confusion
possible pour savoir si le document est ouvert ou pas! en effet imagine que
tu es un problème sur le poste local (plantage, etc..) le cookie ne serait
pas mis à jour....
Il faut t'orienter vers les requêtes car : - j'ai l'impréssion que les requêtes pour ton cas ne sont pas lourdes du tout - c'est plus sur car les infos sont centralisés et donc pas de confusion possible pour savoir si le document est ouvert ou pas! en effet imagine que tu es un problème sur le poste local (plantage, etc..) le cookie ne serait pas mis à jour....
@+
--
oragoun
Sebastien ecrivait dans news:416fe432$0$28164$:
et repasse
à 0 quand cette personne quitte la page pour que quelqu'un d'autre puisse y acceder.
Et si la personne ferme son navigateur sans changer de page ?
Bien vu, faut que je rajoute ça. Donc faut que je fasse "quitte la page ou quitte le soft".
Effectivement, les requêtes SQL sont un goulot d'étranglement, mais du moment que ta BdD est bien pensée et correctement optimisée (voir article sur www.phpinfo.net) tu peux en faire sans souci plus d'une dizaine par page, d'ailleurs des CMS comme phpNuke en font facilement une cinquantaine (évite de suivre cet exemple).
D'accord. En fait je me demandais à quel point ça alourdissait.
De plus ton nouveau site a l'air d'avoir besoin d'un certain dynamisme qu'un système de cache ne pourrait pas te fournir.
Ok.
Un exemple intéressant de cache SQL : afficher une page d'accueil (qui doit être la plus rapide d'un site) les 10 dernières discussions du forum. Le cache serait remis à jour toutes les 5 minutes. S'il y a décalage avec la réalité ce n'est pas grave, ce n'est qu'un forum, alors que dans ton cas le travail d'un utilisateur risque d'être perdu. À utiliser ou non selon les cas.
Ok, donc pas de cache mais un champs.
Merci
oragoun
--
Effacez "_nospam_" si vous desirez me repondre en prive Delete "_nospam_" for private answer Le "Reply To" est valide
--
Sebastien <nospam@for.me> ecrivait dans
news:416fe432$0$28164$636a15ce@news.free.fr:
et repasse
à 0 quand cette personne quitte la page pour que quelqu'un d'autre
puisse y acceder.
Et si la personne ferme son navigateur sans changer de page ?
Bien vu, faut que je rajoute ça. Donc faut que je fasse "quitte la page ou
quitte le soft".
Effectivement, les requêtes SQL sont un goulot d'étranglement, mais du
moment que ta BdD est bien pensée et correctement optimisée (voir
article sur www.phpinfo.net) tu peux en faire sans souci plus d'une
dizaine par page, d'ailleurs des CMS comme phpNuke en font facilement
une cinquantaine (évite de suivre cet exemple).
D'accord. En fait je me demandais à quel point ça alourdissait.
De plus ton nouveau site a l'air d'avoir besoin d'un certain dynamisme
qu'un système de cache ne pourrait pas te fournir.
Ok.
Un exemple intéressant de cache SQL : afficher une page d'accueil (qui
doit être la plus rapide d'un site) les 10 dernières discussions du
forum. Le cache serait remis à jour toutes les 5 minutes.
S'il y a décalage avec la réalité ce n'est pas grave, ce n'est qu'un
forum, alors que dans ton cas le travail d'un utilisateur risque
d'être perdu.
À utiliser ou non selon les cas.
Ok, donc pas de cache mais un champs.
Merci
oragoun
--
oragoun_b_nospam_@yahoo.fr
Effacez "_nospam_" si vous desirez me repondre en prive
Delete "_nospam_" for private answer
Le "Reply To" est valide
à 0 quand cette personne quitte la page pour que quelqu'un d'autre puisse y acceder.
Et si la personne ferme son navigateur sans changer de page ?
Bien vu, faut que je rajoute ça. Donc faut que je fasse "quitte la page ou quitte le soft".
Effectivement, les requêtes SQL sont un goulot d'étranglement, mais du moment que ta BdD est bien pensée et correctement optimisée (voir article sur www.phpinfo.net) tu peux en faire sans souci plus d'une dizaine par page, d'ailleurs des CMS comme phpNuke en font facilement une cinquantaine (évite de suivre cet exemple).
D'accord. En fait je me demandais à quel point ça alourdissait.
De plus ton nouveau site a l'air d'avoir besoin d'un certain dynamisme qu'un système de cache ne pourrait pas te fournir.
Ok.
Un exemple intéressant de cache SQL : afficher une page d'accueil (qui doit être la plus rapide d'un site) les 10 dernières discussions du forum. Le cache serait remis à jour toutes les 5 minutes. S'il y a décalage avec la réalité ce n'est pas grave, ce n'est qu'un forum, alors que dans ton cas le travail d'un utilisateur risque d'être perdu. À utiliser ou non selon les cas.
Ok, donc pas de cache mais un champs.
Merci
oragoun
--
Effacez "_nospam_" si vous desirez me repondre en prive Delete "_nospam_" for private answer Le "Reply To" est valide
--
oragoun
Guillaume BOUCHARD ecrivait dans news:ckobc5$hs8$:
oragoun wrote:
Bonjour,
Bonjour.
J'ai le cas de documents (listes) que plusieurs personnes doivent pouvoir mettre à jour.
Comment sont stocké ces documents ?
BDD. Tableaux pour la visu et formulaires pour l'édition.
Et n'oublie pas un systeme d'expiration de session de modification pour éviter que quelqu'un qui (plante, ferme son navigateur, oublie sa fenetre) ne bloque le document pendant un temps trop long voir illimité... Et betonne bien le concept, parce qu'il n'est pas rare qu'un "verrou" de ce style reste activé. (ma derniere experience date de 2 jours où un prog ne se lancait plus à cause d'un fichier lock qui etait resté.)
Bon, ça fait pas mal de choses à prévoir ;o). Tant mieux, ça va me faire progresser.
Dans le détail : - ferme son navigateur : ok, javascript. - oublie sa fenetre : ok, test sur l'expiration de session. - plante : La je seche. S'il y a deconnexion "brutale", comment le serveur peut-il savoir que la session est close, que le champs "used" doit repasser à 0? Ou il y a quelque chose que je n'ai pas compris dans le fonctionnement des sessions, ce qui est fort possible.
Maitenant, ce genre de chose me fais penser au concept de wiki. Esseye de voir comment les "grands" scripts de wiki gerent ce problème et tu aura sans doute une reponse plus adapté.
Bonne piste, merci.
oragoun
--
Effacez "_nospam_" si vous desirez me repondre en prive Delete "_nospam_" for private answer Le "Reply To" est valide
--
Guillaume BOUCHARD <guillaume_fclp@apinc.org> ecrivait dans
news:ckobc5$hs8$1@demo2.univ-lyon1.fr:
oragoun wrote:
Bonjour,
Bonjour.
J'ai le cas de documents (listes) que plusieurs
personnes doivent pouvoir mettre à jour.
Comment sont stocké ces documents ?
BDD. Tableaux pour la visu et formulaires pour l'édition.
Et n'oublie pas un systeme d'expiration de session de modification
pour éviter que quelqu'un qui (plante, ferme son navigateur, oublie sa
fenetre) ne bloque le document pendant un temps trop long voir
illimité... Et betonne bien le concept, parce qu'il n'est pas rare
qu'un "verrou" de ce style reste activé. (ma derniere experience date
de 2 jours où un prog ne se lancait plus à cause d'un fichier lock qui
etait resté.)
Bon, ça fait pas mal de choses à prévoir ;o). Tant mieux, ça va me faire
progresser.
Dans le détail :
- ferme son navigateur : ok, javascript.
- oublie sa fenetre : ok, test sur l'expiration de session.
- plante : La je seche. S'il y a deconnexion "brutale", comment le serveur
peut-il savoir que la session est close, que le champs "used" doit repasser
à 0? Ou il y a quelque chose que je n'ai pas compris dans le fonctionnement
des sessions, ce qui est fort possible.
Maitenant, ce genre de chose me fais penser au concept de wiki. Esseye
de voir comment les "grands" scripts de wiki gerent ce problème et tu
aura sans doute une reponse plus adapté.
Bonne piste, merci.
oragoun
--
oragoun_b_nospam_@yahoo.fr
Effacez "_nospam_" si vous desirez me repondre en prive
Delete "_nospam_" for private answer
Le "Reply To" est valide
Guillaume BOUCHARD ecrivait dans news:ckobc5$hs8$:
oragoun wrote:
Bonjour,
Bonjour.
J'ai le cas de documents (listes) que plusieurs personnes doivent pouvoir mettre à jour.
Comment sont stocké ces documents ?
BDD. Tableaux pour la visu et formulaires pour l'édition.
Et n'oublie pas un systeme d'expiration de session de modification pour éviter que quelqu'un qui (plante, ferme son navigateur, oublie sa fenetre) ne bloque le document pendant un temps trop long voir illimité... Et betonne bien le concept, parce qu'il n'est pas rare qu'un "verrou" de ce style reste activé. (ma derniere experience date de 2 jours où un prog ne se lancait plus à cause d'un fichier lock qui etait resté.)
Bon, ça fait pas mal de choses à prévoir ;o). Tant mieux, ça va me faire progresser.
Dans le détail : - ferme son navigateur : ok, javascript. - oublie sa fenetre : ok, test sur l'expiration de session. - plante : La je seche. S'il y a deconnexion "brutale", comment le serveur peut-il savoir que la session est close, que le champs "used" doit repasser à 0? Ou il y a quelque chose que je n'ai pas compris dans le fonctionnement des sessions, ce qui est fort possible.
Maitenant, ce genre de chose me fais penser au concept de wiki. Esseye de voir comment les "grands" scripts de wiki gerent ce problème et tu aura sans doute une reponse plus adapté.
Bonne piste, merci.
oragoun
--
Effacez "_nospam_" si vous desirez me repondre en prive Delete "_nospam_" for private answer Le "Reply To" est valide
--
Guillaume BOUCHARD
oragoun wrote:
Bon, ça fait pas mal de choses à prévoir ;o). Tant mieux, ça va me faire progresser.
Bonne vision des choses.
Dans le détail : - ferme son navigateur : ok, javascript.
A mort !!!
Il ne faut /*_JAMAIS_*/ faire confiance à un langage coté client pour s'occuper de l'integrité des données.
- oublie sa fenetre : ok, test sur l'expiration de session.
Ok, à conditions que tu geres tes sessions à la main, car je ne crois pas que PHP soit capable de te prevenir qu'une session a expiré avec la gestion des sessions interne.
- plante : La je seche. S'il y a deconnexion "brutale", comment le serveur peut-il savoir que la session est close, que le champs "used" doit repasser à 0? Ou il y a quelque chose que je n'ai pas compris dans le fonctionnement des sessions, ce qui est fort possible.
Meme principe, tu tests l'expiration de la session.
-- Guillaume.
--
oragoun wrote:
Bon, ça fait pas mal de choses à prévoir ;o). Tant mieux, ça va me faire
progresser.
Bonne vision des choses.
Dans le détail :
- ferme son navigateur : ok, javascript.
A mort !!!
Il ne faut /*_JAMAIS_*/ faire confiance à un langage coté client pour
s'occuper de l'integrité des données.
- oublie sa fenetre : ok, test sur l'expiration de session.
Ok, à conditions que tu geres tes sessions à la main, car je ne crois
pas que PHP soit capable de te prevenir qu'une session a expiré avec la
gestion des sessions interne.
- plante : La je seche. S'il y a deconnexion "brutale", comment le serveur
peut-il savoir que la session est close, que le champs "used" doit repasser
à 0? Ou il y a quelque chose que je n'ai pas compris dans le fonctionnement
des sessions, ce qui est fort possible.
Meme principe, tu tests l'expiration de la session.
Bon, ça fait pas mal de choses à prévoir ;o). Tant mieux, ça va me faire progresser.
Bonne vision des choses.
Dans le détail : - ferme son navigateur : ok, javascript.
A mort !!!
Il ne faut /*_JAMAIS_*/ faire confiance à un langage coté client pour s'occuper de l'integrité des données.
- oublie sa fenetre : ok, test sur l'expiration de session.
Ok, à conditions que tu geres tes sessions à la main, car je ne crois pas que PHP soit capable de te prevenir qu'une session a expiré avec la gestion des sessions interne.
- plante : La je seche. S'il y a deconnexion "brutale", comment le serveur peut-il savoir que la session est close, que le champs "used" doit repasser à 0? Ou il y a quelque chose que je n'ai pas compris dans le fonctionnement des sessions, ce qui est fort possible.
Meme principe, tu tests l'expiration de la session.
-- Guillaume.
--
oragoun
Guillaume BOUCHARD ecrivait dans news:cl2sli$c6v$:
oragoun wrote:
Dans le détail : - ferme son navigateur : ok, javascript.
A mort !!!
Il ne faut /*_JAMAIS_*/ faire confiance à un langage coté client pour s'occuper de l'integrité des données.
Ok ok ;o)). Faut que je me replonge dans le chapitre "sessions" de mon bouquin.
- oublie sa fenetre : ok, test sur l'expiration de session.
Ok, à conditions que tu geres tes sessions à la main, car je ne crois pas que PHP soit capable de te prevenir qu'une session a expiré avec la gestion des sessions interne.
A chaque manip, enregistrement de l'heure dans le cookie de session et une boucle qui verifie que trop de temps n'est pas passé depuis la derniere manip. Enfin c'est à ça que je pensais.
- plante : La je seche. S'il y a deconnexion "brutale", comment le serveur peut-il savoir que la session est close, que le champs "used" doit repasser à 0? Ou il y a quelque chose que je n'ai pas compris dans le fonctionnement des sessions, ce qui est fort possible.
Meme principe, tu tests l'expiration de la session.
Coté serveur? Ca je sais pas faire. Coté client, s'il a planté "pour de vrai", je ne vois pas comment faire un test.
oragoun
--
Effacez "_nospam_" si vous desirez me repondre en prive Delete "_nospam_" for private answer Le "Reply To" est valide
--
Guillaume BOUCHARD <guillaume_fclp@apinc.org> ecrivait dans
news:cl2sli$c6v$1@demo2.univ-lyon1.fr:
oragoun wrote:
Dans le détail :
- ferme son navigateur : ok, javascript.
A mort !!!
Il ne faut /*_JAMAIS_*/ faire confiance à un langage coté client pour
s'occuper de l'integrité des données.
Ok ok ;o)). Faut que je me replonge dans le chapitre "sessions" de mon
bouquin.
- oublie sa fenetre : ok, test sur l'expiration de session.
Ok, à conditions que tu geres tes sessions à la main, car je ne crois
pas que PHP soit capable de te prevenir qu'une session a expiré avec
la gestion des sessions interne.
A chaque manip, enregistrement de l'heure dans le cookie de session et une
boucle qui verifie que trop de temps n'est pas passé depuis la derniere
manip. Enfin c'est à ça que je pensais.
- plante : La je seche. S'il y a deconnexion "brutale", comment le
serveur peut-il savoir que la session est close, que le champs "used"
doit repasser à 0? Ou il y a quelque chose que je n'ai pas compris
dans le fonctionnement des sessions, ce qui est fort possible.
Meme principe, tu tests l'expiration de la session.
Coté serveur? Ca je sais pas faire. Coté client, s'il a planté "pour de
vrai", je ne vois pas comment faire un test.
oragoun
--
oragoun_b_nospam_@yahoo.fr
Effacez "_nospam_" si vous desirez me repondre en prive
Delete "_nospam_" for private answer
Le "Reply To" est valide
Guillaume BOUCHARD ecrivait dans news:cl2sli$c6v$:
oragoun wrote:
Dans le détail : - ferme son navigateur : ok, javascript.
A mort !!!
Il ne faut /*_JAMAIS_*/ faire confiance à un langage coté client pour s'occuper de l'integrité des données.
Ok ok ;o)). Faut que je me replonge dans le chapitre "sessions" de mon bouquin.
- oublie sa fenetre : ok, test sur l'expiration de session.
Ok, à conditions que tu geres tes sessions à la main, car je ne crois pas que PHP soit capable de te prevenir qu'une session a expiré avec la gestion des sessions interne.
A chaque manip, enregistrement de l'heure dans le cookie de session et une boucle qui verifie que trop de temps n'est pas passé depuis la derniere manip. Enfin c'est à ça que je pensais.
- plante : La je seche. S'il y a deconnexion "brutale", comment le serveur peut-il savoir que la session est close, que le champs "used" doit repasser à 0? Ou il y a quelque chose que je n'ai pas compris dans le fonctionnement des sessions, ce qui est fort possible.
Meme principe, tu tests l'expiration de la session.
Coté serveur? Ca je sais pas faire. Coté client, s'il a planté "pour de vrai", je ne vois pas comment faire un test.
oragoun
--
Effacez "_nospam_" si vous desirez me repondre en prive Delete "_nospam_" for private answer Le "Reply To" est valide
--
Guillaume BOUCHARD
oragoun wrote:
A chaque manip, enregistrement de l'heure dans le cookie de session et une boucle qui verifie que trop de temps n'est pas passé depuis la derniere manip. Enfin c'est à ça que je pensais.
Mais si ton utilisateur ne reviens pas sur le site ? Il n'y aura pas cette manip.
-- Guillaume.
--
oragoun wrote:
A chaque manip, enregistrement de l'heure dans le cookie de session et une
boucle qui verifie que trop de temps n'est pas passé depuis la derniere
manip. Enfin c'est à ça que je pensais.
Mais si ton utilisateur ne reviens pas sur le site ? Il n'y aura pas
cette manip.
A chaque manip, enregistrement de l'heure dans le cookie de session et une boucle qui verifie que trop de temps n'est pas passé depuis la derniere manip. Enfin c'est à ça que je pensais.
Mais si ton utilisateur ne reviens pas sur le site ? Il n'y aura pas cette manip.
