Oui mais comme dit Fil c'est trop compliqué : comment sais-tu à l'avance
si une boucle doit être recalculée ou non ? Ca nécessiterait un système
de dépendances hyper couillu (avec des poils).
Je te laisse les commentaires très mecs que les femmes apprécient
tant dans les listes...
Un article, il est dans une rubrique, avec d'autres articles. C'est ce
qui importe. Les boucles, c'est que la façon de les présenter.
Micro$ a tellement appris à clicker que c'est devenu une drogue.
C'est si grave ?
C'est pas grave. Le monde médical sera heureux d'avoir encore plus
de tendinites du click à soigner...
Je pourrais aussi voir comment envoyer un email aux développeurs à chaque
"Recalculer cette page". Ainsi ces clicks inutiles pourraient devenir
utiles
Je te laisse les commentaires très mecs que les femmes apprécient
tant dans les listes...
Boh si on peut plus rigoler...
C'est si grave ?
C'est pas grave. Le monde médical sera heureux d'avoir encore plus
de tendinites du click à soigner...
Je pourrais aussi voir comment envoyer un email aux développeurs à chaque
"Recalculer cette page". Ainsi ces clicks inutiles pourraient devenir
utiles
Dis-moi, je n'ai pas l'impression que vous ayez aprlé de "vider le
cache" dans les fonctions d'administration.
Il y a un contexte qui m'échappe, ou bien ?
Parce que quand je fais une modif qui doit impacter des tas de pages[1],
je vide le cache et basta. Je n'ai jamais ressenti le besoin d'avoir une
fonction qui viderait avec discernement une arbo spécifique. Et de plus
comment le script pourrait deviner où apparaissent les infos de
l'article. Tiens par exemple sur mon site perso j'ai une page "auteur"
avec les quelques derniers articles de l'auteur. Comment spip peut
savoir que cette page aussi doit être recalculée, à moins d'une fonction
très très perverse qui parcourt tous les squelettes, vérifie dans
lesquels la condition est vérifiée("ici il y a une boucle articles et en
plus elle intègre pile l'article que je viens de modifier"), et fait les
MAJ nécessaires ?
Donc pour moi il n'y a pas qu'une question de flemme des spip-core-devs
mais aussi une question de volume de script pour pas grand-chose : le
bouton "vider le cache" est ton ami.
[1] à mon bureau on a comme tout le monde le sommaire qui comporte une
zone "quoi de neuf", les pages de listes d'articles, des menus inclus
dans l'ensemble des pages du site, le plan du site, et euh-- c'est tout
je crois. (Yann, je n'oublie rien ? ;-))
Pout ma part, je suis d'accord avec Anne Possoz qu'il est dommage que la modif
d'un article ou autre ne déclenche pas l'exclusion des seuls caches concernés
(mais c'est moins genant pour l'auteur de la modif que pour ceux qui ne savent pas que cette modif est survenue). Et le script peut connaitre les caches concernés: le procédé est déjà en place pour les forums, l'envoi d'un message dans un forum vidant les caches concernés
(le nom de ceux-ci et sa dépendance à ce forum sont mémorisés lors de l'exécution du squelette,
par une instruction rajoutée par le compilateur). Il faudrait donc généraliser ça à tout ce qui
est modifiable, pas seulement les forums. Malheureusement PHP/MySQL ne nous y aide pas:
c'est l'équivalent des "triggers" de PostGres ou Oracle, mais en leur absence il faut programmer
tout ce mécanisme soi-meme, ce n'est pas rien.
Ça n'a rien à voir à mon avis.
Tu ne va pas mettre un trigger sur le select pour dire "tiens, on viens
de me demander l'article 42, donc je note que l'appelant doit être
décaché à la prochaine modif de l'article 42". Premièrement, mysql ne
sait pas qui est l'appelant. Deuxièmement, si l'appelant c'est
l'interface d'admin, t'as pas fini de décacher.
Tu ne va pas mettre un trigger sur le select pour dire "tiens, on viens
de me demander l'article 42, donc je note que l'appelant doit être
décaché à la prochaine modif de l'article 42". Premièrement, mysql ne
sait pas qui est l'appelant. Deuxièmement, si l'appelant c'est
l'interface d'admin, t'as pas fini de décacher.
C'est pourtant ce qui est fait pour les forums:
"tiens je viens de créer C, cache de l'article N qui inclut les forums X Y Z,
je mets dans la table spip_forum_cache qu'une modif de X Y ou Z devra effacer le cache C".
Et effectivement, la fonction PHP ajout_forum parcourt cette table pour trouver les caches à
effacer, en l'absence de trigger qui déclencherait ça au niveau SQL automatiquement.
La connaissance de l'appelant est l'oeuvre du compilateur (fonction calculer_boucle)
qui fait mémoriser le nom du cache par le code qu'il produit dans le cas d'une boucle de forum.
La question est donc de savoir si pour chaque type de boucle, on ne pourrait pas garnir une table
équivalente de sorte que chaque script de modif (donc en plus de inc-forum, ecrire/articles etc)
irait consulter cette table pour détruire exclusivement les caches concernées.
Ca me semble possible, mais il y a peut-etre des cas tordus que je ne vois pas
(en particulier je n'ai pas vu ou est le article_imprimer.php3?id_article=12 dont parle Fil).
Mais je serai curieux de savoir pourquoi tu as bloqué au moins 3 fois.
Déesse A. a comparé la mise à jour d'un article
à celle des forums.
La différence entre les forums et les articles
c'est que les forums sont rédigés par n'importe quel internaute,
avec validation automatique si cette option est retenue,
alors que les articles sont rédigés par ... les rédacteurs,
et que, plus spécifique encore, ils sont validés par ...
un administrateur.
Avec les forums, il y a une pléthore d'acteurs concernés
(potentiellement tous les internautes accédant au site)
et une grande abondance de situation de mise à jour,
qui justifie une mécanique complexe afin de garder
la transparence du site et de l'interactivité
auprès du plus grand nombre des internautes.
Avec les articles, il n'y a QUE les administrateurs
qui sont confrontés à la mise à jour des pages,
et à cette absence de transparence immédiate actuellement.
Or, ce sont les administrateurs qui connaissent le mieux
leur site et les interactions et imbrications de boucles
et de pages ... et qui sont bien placés pour gérer ça
à la main.
