Produits Entr'ouvert » Combo

Il n'y a pas de parcours décrit, ni ici ni dans le ticket lié, je vais imaginer qu'il y a un retour contrôlé vers la page contenant dans la cellule. Il pourrait alors y avoir un ?refresh ajouté à l'URL, et en présence de ce paramètre le cache serait ignoré/vidé; on peut imaginer ça de manière globale mais aussi une variante ?refresh=slug pour concerner uniquement la cellule avec le slug donné.

Ça permet de conserver une utilité au cache.

Dans mon cas d'usage la cellule est affichée sur une page qui dans le menu principal de combo. Il n'y a pas de lien vers cette page autre que celui-là.

On peut donc imaginer que ton entrée de menu contienne ?refresh=le-slug, pour forcer de manière systématique le rafraichissement de la cellule en question. Ça marche pour ton cas, ça garde le cache effectif pour le cas commun qui n'est pas un agent faisant des allers-retours rapides vers sa page d'accueil et ça ne charge pas non plus l'interface de configuration de ces cellules (ce qui est à éviter en attendant un dispositif efficace permettant aux options "rares/avancées" de ne pas prendre de place).

On peut donc imaginer que ton entrée de menu contienne ?refresh=le-slug,

Ah non je pensais menu barre latérale portail agent parce que cette cellule reste prévue pour cet usage mais ici ça n'est pas le cas on est sur une exploitation en front de la cellule.

branche à jour avec correction à des tests et pour pylint.

Et dans ton idée comment somehow cette url ?invalidate-user-cache se trouve appelée ? C'est ajouté dans le workflow ?

Et dans ton idée comment somehow cette url ?invalidate-user-cache se trouve appelée ? C'est ajouté dans le workflow ?

Non ça ne peut pas être ça c'est basé sur l'utilisateur de la requête request.user.pk; hésitation peut-être via PublikAuthentication mais ça dépendrait de DRF or ici il n'y a pas ça.

J'étais toujours sur l'idée qu'on revenait à un moment de w.c.s. vers combo et donc qu'on pouvait passer ce paramètre à ce moment (quelque soit la page retour) PS: que ce soit un lien dans la page (menu) ou une action de redirection dans le workflow, l'action de redirection dans le workflow me semblant le moyen le plus sûr de garantir le parcours et le passage du paramètre effectivement.

De ce que je comprenais au moment de #62678#note-6 il n'y avait justement pas de parcours fléché, qu'il y avait clic dans la navigation principale du site, que justement ça rendait ce jeu de paramètre supplémentaire impraticable. (cf première vidéo de https://portail-mates.test.entrouvert.org/ où les parcours se font pas mal en cliquant sur "espace pro" dans la navigation principale).

Il faudrait expliciter davantage l'idée, tu écris "appelable de n'importe où" mais tu imagines que ça soit utilisé où ? ça serait mis dans une action d'ajout d'un message dans l'historique ?

Je suis vraiment sur l'impression que se construit ici quelque chose dont l'exploitation va être trop compliquée.

(pour moi il y aurait à profiter de l'organisation à venir du paramétrage des cellules pour juste y taper un onglet cache avec une option pour le configurer, permettre des "options plus rares mais utiles dans certains contextes" c'était totalement l'idée #62965, ça matche ici).

Frédéric Péters a écrit :

Il faudrait expliciter davantage l'idée, tu écris "appelable de n'importe où" mais tu imagines que ça soit utilisé où ? ça serait mis dans une action d'ajout d'un message dans l'historique ?

Oui idéalement, ça évite de se demander si la personne va suivre un lien ici où là.

Je suis vraiment sur l'impression que se construit ici quelque chose dont l'exploitation va être trop compliquée.

Ça consiste à ajouter un tag img.

(pour moi il y aurait à profiter de l'organisation à venir du paramétrage des cellules pour juste y taper un onglet cache avec une option pour le configurer, permettre des "options plus rares mais utiles dans certains contextes" c'était totalement l'idée #62965, ça matche ici).

Ça revient à supprimer le cache dans certaines situations, je ne sais pas si c'est mieux mais ça me va d'ouvrir un ticket pour exposer cache_duration (je ne vois pas bien le lien avec #62965 à part que oui la présentation changera), ça faisait partie de mes propositions.

Après je trouve que l'invalidation du cache sur les appels HTTP est un problème récurrent de toute façon (sur les cellules JSON aussi) et que le résoudre par "on supprime le cache" ce n'est pas vraiment le résoudre AMHO. Là on avait un début de solution un peu global.

Oui idéalement, ça évite de se demander si la personne va suivre un lien ici où là.
Ça consiste à ajouter un tag img.

Perso je lis ça comme explication à donner : si vous voulez invalider le cache ajoutez une action "message dans l'historique" dans laquelle vous aurez à copié/collé <img src="{{ portal_url }}/refresh.gif?refresh-user-cache"/> et puis sans doute ça va pourrir un peu l'affichage de l'historique avec des commentaires qui apparaitront vide mais à chaque jour sa peine.

C'est pour moi une exploitation compliquée, ça se trouvera deux fois utilisé au fond d'un workflow puis plus jamais.

je ne vois pas bien le lien avec #62965

Il y a une certaine opposition à ajouter des options rarement utilisées et qui encombrent l'interface. #62965 est le chemin pour conserver une configuration avec les options utiles, tout en se permettant des options plus rares.

je trouve que l'invalidation du cache sur les appels HTTP est un problème récurrent de toute façon

Je suis d'accord.

Là on avait un début de solution un peu global

"un peu global", pas assez, le cadre de réflexion doit être plus large. Ce patch vient en ignorant totalement les problèmes d'invalidation de cache qui peuvent exister dans publik famille, par exemple.

Frédéric Péters a écrit :

Oui idéalement, ça évite de se demander si la personne va suivre un lien ici où là.
Ça consiste à ajouter un tag img.

Perso je lis ça comme explication à donner : si vous voulez invalider le cache ajoutez une action "message dans l'historique" dans laquelle vous aurez à copié/collé <img src="{{ portal_url }}/refresh.gif?refresh-user-cache"/> et puis sans doute ça va pourrir un peu l'affichage de l'historique avec des commentaires qui apparaitront vide mais à chaque jour sa peine.

C'est pour moi une exploitation compliquée, ça se trouvera deux fois utilisé au fond d'un workflow puis plus jamais.

Je suis d'accord que ce n'est pas super propre, mais tant que le cache est lié au front, la notification doit passer par le front, une solution via web-service ne pourra pas viser le bon front. Donc c'est soit ça, soit aller vers un cache cohérent entre les fronts ou trouver une donnée cohérente (genre un compteur par utilisateur stocké en base qui serait ajouté aux clés du cache, comme ici, mais le compteur lui serait global et pas local au front) qui serve de version.

Même à imaginer une solution automatique où w.c.s. viendrait notifier les briques de lui même que pour tel utilisateur les données ont changé (ça ne nécessiterait donc pas de prise en compte particulière par les administrateurs fonctionnels) nécessiterait de résoudre ce problème technique de fond. Ou bien on pourrait dire que dans une telle situation w.c.s. ajoute de lui même ce tag <img> à sa page, mais ça demande plus de boulot pour identifier dans w.c.s. toutes les pages ou cette action devra être faite (plus les cas d'action de redirection dans le workflow, où w.c.s. pourrait éventuellement ajouter de lui même le ?refresh-user-cache s'il identifie une URL du portail), c'est moins de travail pour l'administrateur mais plus de complexité dans le code.

je trouve que l'invalidation du cache sur les appels HTTP est un problème récurrent de toute façon

Je suis d'accord.

Là on avait un début de solution un peu global

"un peu global", pas assez, le cadre de réflexion doit être plus large. Ce patch vient en ignorant totalement les problèmes d'invalidation de cache qui peuvent exister dans publik famille, par exemple.

Je veux bien plus de détails pour voir en quoi ça n'y répond pas pour des cellules fiches ça doit le faire tout seul aussi (pourvu qu'on mette le tag <img> etc... que la modification vienne d'une action dans w.c.s. via un formulaire, etc..).

Je veux bien plus de détails pour voir en quoi ça n'y répond pas pour des cellules fiches ça doit le faire tout seul aussi (pourvu qu'on mette le tag <img> etc... que la modification vienne d'une action dans w.c.s. via un formulaire, etc..).

Et que tout ça soit fait par l'usager.

Ça ignore les manipulations des agents, qui se trouvent à aller modifier l'info pour une famille via un formulaire et puis la modif n'apparait pas sur la page combo associée. (résultat on y a un cache court à 5 secondes pour ignorer le problème).

c'est surtout pour discuter

Je préférerais qu'avant de foncer dans des trucs on prenne du temps pour poser le sujet; les problèmes qu'on rencontre, ce qu'on veut atteindre, les pistes pour y arriver.

(et fermer ce ticket qui a pris une dimension qui le dépasse).

Il me semblait que tu avais créé #63354.