Différence de gestion du cache des box ajax entre SPIP 4.0 et 4.1 ? #4863

Closed
opened 5 months ago by rastapopoulos · 8 comments
Owner

Yop, ceci est à priori un ticket documentation (cependant : les plugins dist du genre mediabox ne sont documentés nulle part ! donc comment on garde la trace des fonctionnalités, les params et attributs data existants etc ?).

Il me semble avoir remarqué une différence de gestion du cache pour les box ajax, pour un même lien "var_zajax" d'un même plugin :

  • en 4.0 qui avait déjà Lity, chaque clic sur le lien génère un chargement du morceau, dans l'onglet Réseau de Firefox
  • en 4.1, la première fois ça charge, puis chaque fois suivante… ça réaffiche juste la même chose tel quel, sans plus aucun rechargement ajax dans Réseau

Est-ce documenté ? Et comment forcer le rechargement à chaque fois ?

Quand le contenu de la box est un formulaire, il est impératif que ça ne réaffiche pas un HTML gardé en mémoire tel quel.

Un rapport avec ce commit ? qui dit, au passage d'une autre fonctionnalité

+fixer le cache ajax quand on a pas d'opener (ce qui est le plus souvent le cas) en stockant sur document dans ce cas

(je ne sais pas ce qu'est un "opener")

Yop, ceci est à priori un ticket documentation (cependant : les plugins dist du genre mediabox ne sont documentés nulle part ! donc comment on garde la trace des fonctionnalités, les params et attributs data existants etc ?). Il me semble avoir remarqué une différence de gestion du cache pour les box ajax, pour un même lien "var_zajax" d'un même plugin : - en 4.0 qui avait déjà Lity, chaque clic sur le lien génère un chargement du morceau, dans l'onglet Réseau de Firefox - en 4.1, la première fois ça charge, puis chaque fois suivante… ça réaffiche juste la même chose tel quel, sans plus aucun rechargement ajax dans Réseau Est-ce documenté ? Et comment forcer le rechargement à chaque fois ? Quand le contenu de la box est un formulaire, il est impératif que ça ne réaffiche pas un HTML gardé en mémoire tel quel. Un rapport [avec ce commit](https://git.spip.net/spip/mediabox/commit/74c918639e709cabe83c3e28e458c29cdfc760bb) ? qui dit, au passage d'une *autre* fonctionnalité > +fixer le cache ajax quand on a pas d'opener (ce qui est le plus souvent le cas) en stockant sur document dans ce cas (je ne sais pas ce qu'est un "opener")
rastapopoulos added the
documentation
label 5 months ago
Owner

J'allais répondre que le fix a rétabli le comportement qu'on avait en 3.2, mais de fait en allant tester c'est pas le cas:

  • en 3.2 la box avec un contenu ajax rechargeait le contenu à chaque ouverture de la box, via un POST xhr (bouh, aucun cache SPIP du coup)
  • en 4.0 la box avec un contenu ajax rechargeait le contenu à chaque ouverture de la box, via un GET xhr, dans la plupart des cas, car le cache implémenté ne marchait que dans certaines conditions d'ouverture spécifique
  • en 4.1, le cache étant réparé, la box avec un contenu ajax charge une première fois le contenu en GET xhr, puis réutilise ce contenu à chaque réouverture (tant qu'on reste sur la même page)

Pour l'histoire : la box lity n'implémente pas de handler pour les contenu ajax, j'ai donc implémenté un handler en m'inspirant du handler image de la box, qui inclue ce mécanisme de cache (ce qui est pertinent pour les images).

Mais donc en fixant #4845 je me suis rendu compte du bug sur le cache dans la plupart des scénarios, et je l'ai corrigé.

Maintenant on a 2 solutions :

  • considérer que ce cache sur les contenus ajax est un bug et une rupture de comportement et revenir à un fonctionnement sans cache (déjà on a un GET au lieu d'un POST, c'est beaucoup mieux qu'en 3.2)
  • considérer que ce cache est une amélioration mais il est parfois embêtant, comme dans le cas que tu cites - encore que la plupart du temps le html de la box ajax contient le formulaire vide, et même si tu le remplis, valide etc, si tu réouvres ta box tu retrouves ton formulaire vide (il y a donc problème uniquement si l'état initial de ton formulaire doit dépendre du fait que tu as déjà soumis le formulaire)

Je serai partisan de garder ce cache donc, et d'ajouter une directive de type data-box-cache="false" sur le lien/bouton d'ouverture qui permet de desactiver le cache des box ajax là où c'est nécessaire.

Est-ce que ça résoudrait ton cas d'usage ?

(parce que si on met le cache a false par défaut et qu'on introduit une directive pour l'activer, il ne sera jamais utilisé)

J'allais répondre que le fix a rétabli le comportement qu'on avait en 3.2, mais de fait en allant tester c'est pas le cas: - en 3.2 la box avec un contenu ajax rechargeait le contenu à chaque ouverture de la box, via un POST xhr (bouh, aucun cache SPIP du coup) - en 4.0 la box avec un contenu ajax rechargeait le contenu à chaque ouverture de la box, via un GET xhr, dans la plupart des cas, car le cache implémenté ne marchait que dans certaines conditions d'ouverture spécifique - en 4.1, le cache étant réparé, la box avec un contenu ajax charge une première fois le contenu en GET xhr, puis réutilise ce contenu à chaque réouverture (tant qu'on reste sur la même page) Pour l'histoire : la box lity n'implémente pas de handler pour les contenu ajax, j'ai donc implémenté un handler en m'inspirant du handler image de la box, qui inclue ce mécanisme de cache (ce qui est pertinent pour les images). Mais donc en fixant #4845 je me suis rendu compte du bug sur le cache dans la plupart des scénarios, et je l'ai corrigé. Maintenant on a 2 solutions : * considérer que ce cache sur les contenus ajax est un bug et une rupture de comportement et revenir à un fonctionnement sans cache (déjà on a un GET au lieu d'un POST, c'est beaucoup mieux qu'en 3.2) * considérer que ce cache est une amélioration mais il est parfois embêtant, comme dans le cas que tu cites - encore que la plupart du temps le html de la box ajax contient le formulaire vide, et même si tu le remplis, valide etc, si tu réouvres ta box tu retrouves ton formulaire vide (il y a donc problème uniquement si l'état initial de ton formulaire doit dépendre du fait que tu as déjà soumis le formulaire) Je serai partisan de garder ce cache donc, et d'ajouter une directive de type `data-box-cache="false"` sur le lien/bouton d'ouverture qui permet de desactiver le cache des box ajax là où c'est nécessaire. Est-ce que ça résoudrait ton cas d'usage ? (parce que si on met le cache a false par défaut et qu'on introduit une directive pour l'activer, il ne sera jamais utilisé)
Poster
Owner

il y a donc problème uniquement si l'état initial de ton formulaire doit dépendre du fait que tu as déjà soumis le formulaire

C'est le cas sur 100% des formulaires de type "contenu", le form étant toujours prérempli avec l'état du contenu (sauf pour la toute première création)

Et du coup… arg ça veut dire que c'est bien un bug, et que la 4.1 est sorti avec, car ça crée des problèmes déjà pour la dist seule, puisque ça le fait au moins pour Médias !

Moi j'avais testé que un plugin en plus (noizetier), mais je viens de retester et je reproduis bien juste avec l'édition des documents qui est dans une box quand on clique sur "Modifier" depuis un contenu qui a des docs : on change les méta infos, titre, description etc, on enregistre, ça met à jour le bloc et quand on remodifie… c'est les anciennes valeurs !

Je serai partisan de garder ce cache donc, et d'ajouter une directive de type data-box-cache="false" sur le lien/bouton d'ouverture qui permet de desactiver le cache des box ajax là où c'est nécessaire.
(parce que si on met le cache a false par défaut et qu'on introduit une directive pour l'activer, il ne sera jamais utilisé)

Je suis plutôt d'accord avec ça oui, moi ça me va du moment qu'il y a bien un truc explicite pour ne pas avoir de cache. (Et qu'on trouve un endroit adéquat pour documenter toute cette API…)

Mais donc bien penser à l'utiliser déjà dans les plugins dist :)


(Au passage en relisant le commit que j'ai pointé, question nomenclature, c'est bien que ce soit toujours la même structure, mais du coup pourquoi "data-href-popin" ? Où là ça parle de "popin" au lieu de "box" + sité en suffixe au lieu d'en préfixe. Ça serait pas mieux "data-box-href" pour suivre pareil partout ?)

> il y a donc problème uniquement si l'état initial de ton formulaire doit dépendre du fait que tu as déjà soumis le formulaire C'est le cas sur 100% des formulaires de type "contenu", le form étant toujours prérempli avec l'état du contenu (sauf pour la toute première création) Et du coup… arg ça veut dire que c'est bien un bug, et que la 4.1 est sorti avec, car ça crée des problèmes déjà pour la dist seule, puisque ça le fait au moins pour Médias ! Moi j'avais testé que un plugin en plus (noizetier), mais je viens de retester et je reproduis bien juste avec l'édition des documents qui est dans une box quand on clique sur "Modifier" depuis un contenu qui a des docs : on change les méta infos, titre, description etc, on enregistre, ça met à jour le bloc et quand on remodifie… c'est les anciennes valeurs ! > Je serai partisan de garder ce cache donc, et d'ajouter une directive de type data-box-cache="false" sur le lien/bouton d'ouverture qui permet de desactiver le cache des box ajax là où c'est nécessaire. > (parce que si on met le cache a false par défaut et qu'on introduit une directive pour l'activer, il ne sera jamais utilisé) Je suis plutôt d'accord avec ça oui, moi ça me va du moment qu'il y a bien un truc explicite pour ne pas avoir de cache. (Et qu'on trouve un endroit adéquat pour documenter toute cette API…) Mais donc bien penser à l'utiliser déjà dans les plugins dist :) ----- (Au passage en relisant le commit que j'ai pointé, question nomenclature, c'est bien que ce soit toujours la même structure, mais du coup pourquoi "data-href-popin" ? Où là ça parle de "popin" au lieu de "box" + sité en suffixe au lieu d'en préfixe. Ça serait pas mieux "data-box-href" pour suivre pareil partout ?)
rastapopoulos added the
bug
label 5 months ago
rastapopoulos added this to the spip-4.1 milestone 5 months ago
Owner

Ah ça va impacter les albums aussi.

Pareil, la solution de demander explicitement qu'on veut pas de cache avec data-box-cache="false" me convient. Faudra bien qu'on pense à documenter ça.

Ah ça va impacter les albums aussi. Pareil, la solution de demander explicitement qu'on veut pas de cache avec `data-box-cache="false"` me convient. Faudra bien qu'on pense à documenter ça.
Owner

En effet je reproduis le bug sur l'édition des documents.

Je vois 2 voies possibles pour corriger le problème

  • stocker le cache des popin ajax dans jQuery.spip.preloaded_urls qui est vidé à chaque post ajax (formulaire ou bouton action)

  • envisager un compromis de gestion du cache de la popin :

    • un comportement par defaut en mode 'auto' : si le contenu ajax contient un <form on ne cache pas, si le contenu ajax ne contient pas de <form on cache
    • un attribut data-box-cache qui permet de forcer le cache (data-box-cache="true") ou de l'inhiber (data-box-cache="false")
En effet je reproduis le bug sur l'édition des documents. Je vois 2 voies possibles pour corriger le problème * stocker le cache des popin ajax dans `jQuery.spip.preloaded_urls` qui est vidé à chaque post ajax (formulaire ou bouton action) * envisager un compromis de gestion du cache de la popin : - un comportement par defaut en mode 'auto' : si le contenu ajax contient un `<form` on ne cache pas, si le contenu ajax ne contient pas de `<form` on cache - un attribut `data-box-cache` qui permet de forcer le cache (`data-box-cache="true"`) ou de l'inhiber (`data-box-cache="false"`)
Owner

01aaaf68eb devrait donc corriger votre problème. Je vous laisse tester et vérifier avant de merger

01aaaf68eb6f836d59312ac20bd6bf2b1918ef31 devrait donc corriger votre problème. Je vous laisse tester et vérifier avant de merger
Poster
Owner

It works for me!

It works for me!
Owner

Pareil

Pareil
cerdic closed this issue 5 months ago
Owner

intégré et reporté en 4.1

intégré et reporté en 4.1
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.