Le navigateur Chrome semble avoir des problèmes de c ache.
16 réponses
Jean Francois Ortolo
Bonjour
Sur mon site : https://www.pronostics-courses.fr , du moins dans les
pages internes de statistiques, je lance en mode Ajax, deux scripts, à
partir du même script, mais évidemment à des endroits différents.
J'ai tout essayé pour faire en sorte qu'il n'y ait pas de cache.
Les données des deux scripts devraient concorder. Elles ne concordent
qu'à partir du deuxième chargement de la page.
Ce problème ne se produit que sous Chrome. Sous Firefox il n'y a pas
de problème.
Ces scripts sont lancés ( en mode Ajax ), avec leur urls en https,
quand j'essaye en http çà ne se lance pas.
J'avoue ... Que tout mes scripts javascript ou Ajax, sont mis dans des fonctions PHP ( avec paramètre ), elles-mêmes contenues dans un script PHP.
Maintenant je vais corriger un tout petit problème de destruction de session non existante, posé par le fait que les appels Ajax sont asynchrones.
Merci beaucoup de votre aide. ;)
Respectueusement.
Jean François Ortolo
SAM
Le 21/02/15 09:17, Jean Francois Ortolo a écrit :
Le 20/02/2015 23:32, SAM a écrit :
Si le PHP a su écrire : adr2='https://www.pronostics-courses.fr/php/courses_anciennes/affichage.php?is_tab=&id_session=p8e9nhbqm1dbds3faom2enbl27 pour lancer l'Ajax
il aurait tout aussi bien pu écrire include('adr2='/php/courses_anciennes/affichage.php?is_tab=&id_session=p8e9nhbqm1dbds3faom2enbl27'); ou similaire.
Et tout le monde aurait été peinard, non ?
Bonjour Monsieur ;)
Vous savez...
que les include se font côté PHP.
oui
( On ne les voit pas côté client ).
toutafé
(sauf à se le faire piquer, il n'y a pas grand intérêt à mettre du code côté client qui ne sert finalement qu'à charger du code serveur et ce, de surcroit, sans intervention du visiteur)
Le JS doit être réservé au "dynamisme", c'est à dire et par exemple : - tri d'un tableau déjà affiché - appel d'un graphique (historique) - requête pour changer de course (le contenu du tableau) - effets graphiques (sauf que là les CSS de nos jours c'est mieux) - etc. *sans changer de page*
Vu que les pages ne rien(*) d'autre que les données il n'y a vraiment pas lieu à faire intervenir du JS pour les charger, ça ira aussi vite sinon plus vite en faisant tout d'un jet côté serveur.
(*) les boutons et divers titres ne doivent pas peser bien lourds ?!
J'avoue ... Que tout mes scripts javascript ou Ajax, sont mis dans des fonctions PHP ( avec paramètre ), elles-mêmes contenues dans un script PHP.
oui, ce peut être possible.
(ou alors on fait du HTML figé, sans script PHP ni le bénéfice d'une BdD)
L'idéal serait que les appels Ajax soient faits suite à action du visiteur (comme de choisir une course dans une ou des listes : jour + lieu + 1ere... nième, par exemple) car là, encore une fois j'enfonce le clou, il n'est absolument pas la peine de faire intervenir aucun JS que ce soit pour, pendant le chargement, compléter des données (fournies par le PHP par extraction à la volée d'une BdD !!) à afficher alors que la page est déjà en construction par le PHP.
Maintenant je vais corriger un tout petit problème de destruction de session non existante, posé par le fait que les appels Ajax sont asynchrones.
Là c'est hors de mes compétences !
D'autant que je ne comprends rien au PHP ! (enfin, quand même, si un peu plus qu'au "turfisme")
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Le 21/02/15 09:17, Jean Francois Ortolo a écrit :
Le 20/02/2015 23:32, SAM a écrit :
Si le PHP a su écrire :
adr2='https://www.pronostics-courses.fr/php/courses_anciennes/affichage.php?is_tab=&id_session=p8e9nhbqm1dbds3faom2enbl27
pour lancer l'Ajax
il aurait tout aussi bien pu écrire
include('adr2='/php/courses_anciennes/affichage.php?is_tab=&id_session=p8e9nhbqm1dbds3faom2enbl27');
ou similaire.
Et tout le monde aurait été peinard, non ?
Bonjour Monsieur ;)
Vous savez...
que les include se font côté PHP.
oui
( On ne les voit pas côté client ).
toutafé
(sauf à se le faire piquer, il n'y a pas grand intérêt à mettre du code
côté client qui ne sert finalement qu'à charger du code serveur et ce,
de surcroit, sans intervention du visiteur)
Le JS doit être réservé au "dynamisme", c'est à dire et par exemple :
- tri d'un tableau déjà affiché
- appel d'un graphique (historique)
- requête pour changer de course (le contenu du tableau)
- effets graphiques (sauf que là les CSS de nos jours c'est mieux)
- etc. *sans changer de page*
Vu que les pages ne rien(*) d'autre que les données il n'y a vraiment
pas lieu à faire intervenir du JS pour les charger, ça ira aussi vite
sinon plus vite en faisant tout d'un jet côté serveur.
(*) les boutons et divers titres ne doivent pas peser bien lourds ?!
J'avoue ... Que tout mes scripts javascript ou Ajax, sont mis dans
des fonctions PHP ( avec paramètre ), elles-mêmes contenues dans un
script PHP.
oui, ce peut être possible.
(ou alors on fait du HTML figé, sans script PHP ni le bénéfice d'une BdD)
L'idéal serait que les appels Ajax soient faits suite à action du
visiteur (comme de choisir une course dans une ou des listes : jour +
lieu + 1ere... nième, par exemple) car là, encore une fois j'enfonce le
clou, il n'est absolument pas la peine de faire intervenir aucun JS que
ce soit pour, pendant le chargement, compléter des données (fournies par
le PHP par extraction à la volée d'une BdD !!) à afficher alors que la
page est déjà en construction par le PHP.
Maintenant je vais corriger un tout petit problème de destruction de
session non existante, posé par le fait que les appels Ajax sont
asynchrones.
Là c'est hors de mes compétences !
D'autant que je ne comprends rien au PHP !
(enfin, quand même, si un peu plus qu'au "turfisme")
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Si le PHP a su écrire : adr2='https://www.pronostics-courses.fr/php/courses_anciennes/affichage.php?is_tab=&id_session=p8e9nhbqm1dbds3faom2enbl27 pour lancer l'Ajax
il aurait tout aussi bien pu écrire include('adr2='/php/courses_anciennes/affichage.php?is_tab=&id_session=p8e9nhbqm1dbds3faom2enbl27'); ou similaire.
Et tout le monde aurait été peinard, non ?
Bonjour Monsieur ;)
Vous savez...
que les include se font côté PHP.
oui
( On ne les voit pas côté client ).
toutafé
(sauf à se le faire piquer, il n'y a pas grand intérêt à mettre du code côté client qui ne sert finalement qu'à charger du code serveur et ce, de surcroit, sans intervention du visiteur)
Le JS doit être réservé au "dynamisme", c'est à dire et par exemple : - tri d'un tableau déjà affiché - appel d'un graphique (historique) - requête pour changer de course (le contenu du tableau) - effets graphiques (sauf que là les CSS de nos jours c'est mieux) - etc. *sans changer de page*
Vu que les pages ne rien(*) d'autre que les données il n'y a vraiment pas lieu à faire intervenir du JS pour les charger, ça ira aussi vite sinon plus vite en faisant tout d'un jet côté serveur.
(*) les boutons et divers titres ne doivent pas peser bien lourds ?!
J'avoue ... Que tout mes scripts javascript ou Ajax, sont mis dans des fonctions PHP ( avec paramètre ), elles-mêmes contenues dans un script PHP.
oui, ce peut être possible.
(ou alors on fait du HTML figé, sans script PHP ni le bénéfice d'une BdD)
L'idéal serait que les appels Ajax soient faits suite à action du visiteur (comme de choisir une course dans une ou des listes : jour + lieu + 1ere... nième, par exemple) car là, encore une fois j'enfonce le clou, il n'est absolument pas la peine de faire intervenir aucun JS que ce soit pour, pendant le chargement, compléter des données (fournies par le PHP par extraction à la volée d'une BdD !!) à afficher alors que la page est déjà en construction par le PHP.
Maintenant je vais corriger un tout petit problème de destruction de session non existante, posé par le fait que les appels Ajax sont asynchrones.
Là c'est hors de mes compétences !
D'autant que je ne comprends rien au PHP ! (enfin, quand même, si un peu plus qu'au "turfisme")
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Jean Francois Ortolo
Le 21/02/2015 09:55, SAM a écrit :
Le 20/02/2015 23:32, SAM a écrit :
(sauf à se le faire piquer, il n'y a pas grand intérêt à mettre du code côté client qui ne sert finalement qu'à charger du code serveur et ce, de surcroit, sans intervention du visiteur)
Le JS doit être réservé au "dynamisme", c'est à dire et par exemple : - tri d'un tableau déjà affiché - appel d'un graphique (historique) - requête pour changer de course (le contenu du tableau) - effets graphiques (sauf que là les CSS de nos jours c'est mieux) - etc. *sans changer de page*
Bonjour Monsieur
C'est pour éviter la copie automatique de mes données par d'autres sites de Turf.
Là, les données ne sont pas visibles dans le code html.
Respectueusement.
Jean François Ortolo
Le 21/02/2015 09:55, SAM a écrit :
Le 20/02/2015 23:32, SAM a écrit :
(sauf à se le faire piquer, il n'y a pas grand intérêt à mettre du code
côté client qui ne sert finalement qu'à charger du code serveur et ce,
de surcroit, sans intervention du visiteur)
Le JS doit être réservé au "dynamisme", c'est à dire et par exemple :
- tri d'un tableau déjà affiché
- appel d'un graphique (historique)
- requête pour changer de course (le contenu du tableau)
- effets graphiques (sauf que là les CSS de nos jours c'est mieux)
- etc. *sans changer de page*
Bonjour Monsieur
C'est pour éviter la copie automatique de mes données par d'autres
sites de Turf.
Là, les données ne sont pas visibles dans le code html.
(sauf à se le faire piquer, il n'y a pas grand intérêt à mettre du code côté client qui ne sert finalement qu'à charger du code serveur et ce, de surcroit, sans intervention du visiteur)
Le JS doit être réservé au "dynamisme", c'est à dire et par exemple : - tri d'un tableau déjà affiché - appel d'un graphique (historique) - requête pour changer de course (le contenu du tableau) - effets graphiques (sauf que là les CSS de nos jours c'est mieux) - etc. *sans changer de page*
Bonjour Monsieur
C'est pour éviter la copie automatique de mes données par d'autres sites de Turf.
Là, les données ne sont pas visibles dans le code html.
Respectueusement.
Jean François Ortolo
SAM
Le 21/02/15 10:23, Jean Francois Ortolo a écrit :
Le 21/02/2015 09:55, SAM a écrit :
(sauf à se le faire piquer, il n'y a pas grand intérêt à mettre du code côté client qui ne sert finalement qu'à charger du code serveur et ce, de surcroit, sans intervention du visiteur)
Bonjour Monsieur
C'est pour éviter la copie automatique de mes données par d'autres sites de Turf.
Ha! OK !
en effet, ya un truc qui fait se recharger en continu la page sauvegardée
Là, les données ne sont pas visibles dans le code html.
Mais on peut les voir quand même (puisque affichées) et les extraire du code html définitif !!!!
Hop! Regarde : <http://stephane.moriaux.pagesperso-orange.fr/truc/turf/> le view-source te montrera ton exact code (avec sa complexité hTML et CSS)
Bon, ce n'est pas si simple. Même si ça me prend 30 secondes par page/course. (+ 1mn / page pour les organiser ?)
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Le 21/02/15 10:23, Jean Francois Ortolo a écrit :
Le 21/02/2015 09:55, SAM a écrit :
(sauf à se le faire piquer, il n'y a pas grand intérêt à mettre du code
côté client qui ne sert finalement qu'à charger du code serveur et ce,
de surcroit, sans intervention du visiteur)
Bonjour Monsieur
C'est pour éviter la copie automatique de mes données par d'autres
sites de Turf.
Ha! OK !
en effet, ya un truc qui fait se recharger en continu la page sauvegardée
Là, les données ne sont pas visibles dans le code html.
Mais on peut les voir quand même (puisque affichées) et les extraire du
code html définitif !!!!
Hop! Regarde :
<http://stephane.moriaux.pagesperso-orange.fr/truc/turf/>
le view-source te montrera ton exact code (avec sa complexité hTML et CSS)
Bon, ce n'est pas si simple.
Même si ça me prend 30 secondes par page/course.
(+ 1mn / page pour les organiser ?)
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
(sauf à se le faire piquer, il n'y a pas grand intérêt à mettre du code côté client qui ne sert finalement qu'à charger du code serveur et ce, de surcroit, sans intervention du visiteur)
Bonjour Monsieur
C'est pour éviter la copie automatique de mes données par d'autres sites de Turf.
Ha! OK !
en effet, ya un truc qui fait se recharger en continu la page sauvegardée
Là, les données ne sont pas visibles dans le code html.
Mais on peut les voir quand même (puisque affichées) et les extraire du code html définitif !!!!
Hop! Regarde : <http://stephane.moriaux.pagesperso-orange.fr/truc/turf/> le view-source te montrera ton exact code (avec sa complexité hTML et CSS)
Bon, ce n'est pas si simple. Même si ça me prend 30 secondes par page/course. (+ 1mn / page pour les organiser ?)
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
