Améliorer ou remplacer affichage_final pour avoir un contexte déjà prêt pour les squelettes racines #4972

Open
opened 11 months ago by rastapopoulos · 4 comments
Owner

Contexte, si j'ose dire : recuperer_fond c'est super, ya plein d'infos, mais ça ne fonctionne que pour les inclusions, si je ne m'abuse (information manquante/trompeuse dans la doc, à corriger au passage).

affichage_final est donc le seul moyen pour la page entière, pour les "squelettes racines", sauf qu'il n'y a rigoureusement aucune info, aucun "args". Alors que pourtant, à ce moment là, on est déjà passé par assembler et on est censé avoir déjà compilé toutes les infos possibles (est-ce que c'est une page= ou un objet éditorial, lequel, quel id ou quelle page, etc).

Si on veut ajouter des choses dans la page, dans le header ou autre, par ex des styles CSS, mais que possiblement ça puisse être différent suivant les pages/contenus, il faut des informations de contexte (et faut pas que ce soit mis dans un cache unique).

Comment faire au mieux du coup pour savoir "où on est", sans que ce soit chacun qui fait sa ptite méthode dans son coin + sans dupliquer du code + sans devoir refaire des calculs compliqués alors qu'on est "à chaque hit" dans cet affichage final, et qu'il faut être le moins couteux possible ?

Je vois trois grandes pistes (dont je ne sais pas trop évaluer la facilité, n'y connaissant pas grand chose en compilateur) :

  • qu'il n'y ait plus de distinction et que les squelettes racines passent aussi par recuperer_fond,
    • soit en rangeant au mieux ce qu'il y a dans public.php et en pouvant appeler la fonction à la fin,
    • soit en laissant encore en bordel hors fonction mais en réussissant à appeler aussi le pipeline à la fin avec les bonnes informations dedans. D'ailleurs au tout début du fichier il y a toujours cette phrase d'il y a 13 ans : "(cette distinction est obsolete a present, on la garde provisoirement par souci de compatiilite)" mais pourtant c'est toujours séparé.
      C'est peut-être le plus compliqué, mais le plus "propre" à terme si on peut y arriver ?
  • ajouter un nouveau pipeline du même genre que affichage_final, au même endroit MAIS un pipeline argumenté (affichage_final_contexte ou que sais-je) avec toutes les infos de contexte déjà sous la main, donc comme ça ya pas à refaire de recherches, de calculs, etc pour tenter chacun dans son coin
  • garder affichage_final mais que SPIP fournisse de base une fonction récupérant le max d'infos de contexte, à partir de $GLOBALS['page'] et autres merdouilles dans le genre, et que du coup quand on s'inscrit ici, on puisse l'appeler et avoir ces infos sous la main de manière "officielle", avec ce qui est considéré comme le plus vrai, le mieux calculé, par celleux qui connaissent. Ça me parait le moins propre, obligé d'utiliser que des globales moches, alors que dans public.php et assembler.php on a moult infos déjà calculées, on les a sous la main, et donc on devrait être capable des les fournir dès l'appel du pipeline (sauf que forcément dans ce cas faut changer de nom pour un nouveau car on peut pas péter l'existant en rajoutant args/data)

Est-ce des gens qui connaissent peuvent aiguiller sur ce qui serait le plus propre à faire ?

Contexte, si j'ose dire : `recuperer_fond` c'est super, ya plein d'infos, mais ça ne fonctionne que pour les inclusions, si je ne m'abuse ([information manquante/trompeuse dans la doc](https://programmer.spip.net/recuperer_fond-209), à corriger au passage). `affichage_final` est donc le seul moyen pour la page entière, pour les "squelettes racines", sauf qu'il n'y a rigoureusement **aucune** info, aucun "args". Alors que pourtant, à ce moment là, on est déjà passé par `assembler` et on est censé avoir déjà compilé toutes les infos possibles (est-ce que c'est une page= ou un objet éditorial, lequel, quel id ou quelle page, etc). Si on veut ajouter des choses dans la page, dans le header ou autre, par ex des styles CSS, mais que possiblement ça puisse être différent suivant les pages/contenus, il faut des informations de contexte (et faut pas que ce soit mis dans un cache unique). Comment faire au mieux du coup pour savoir "où on est", sans que ce soit chacun qui fait sa ptite méthode dans son coin + sans dupliquer du code + sans devoir refaire des calculs compliqués alors qu'on est "à chaque hit" dans cet affichage final, et qu'il faut être le moins couteux possible ? Je vois trois grandes pistes (dont je ne sais pas trop évaluer la facilité, n'y connaissant pas grand chose en compilateur) : - qu'il n'y ait plus de distinction et que les squelettes racines passent *aussi* par `recuperer_fond`, - soit en rangeant au mieux ce qu'il y a dans public.php et en pouvant appeler la fonction à la fin, - soit en laissant encore en bordel hors fonction mais en réussissant à appeler aussi le pipeline à la fin avec les bonnes informations dedans. D'ailleurs au tout début du fichier il y a toujours cette phrase d'il y a 13 ans : "[(cette distinction est obsolete a present, on la garde provisoirement par souci de compatiilite)](https://git.spip.net/spip/spip/src/branch/master/ecrire/public.php#L20)" mais pourtant c'est toujours séparé. C'est peut-être le plus compliqué, mais le plus "propre" à terme si on peut y arriver ? - ajouter un nouveau pipeline du même genre que `affichage_final`, au même endroit MAIS un pipeline argumenté (`affichage_final_contexte` ou que sais-je) avec toutes les infos de contexte *déjà sous la main*, donc comme ça ya pas à refaire de recherches, de calculs, etc pour tenter chacun dans son coin - garder `affichage_final` mais que SPIP fournisse de base une fonction récupérant le max d'infos de contexte, à partir de `$GLOBALS['page']` et autres merdouilles dans le genre, et que du coup quand on s'inscrit ici, on puisse l'appeler et avoir ces infos sous la main de manière "officielle", avec ce qui est considéré comme le plus vrai, le mieux calculé, par celleux qui connaissent. Ça me parait le moins propre, obligé d'utiliser que des globales moches, alors que dans public.php et assembler.php on a moult infos déjà calculées, on les a sous la main, et donc on devrait être capable des les fournir *dès l'appel* du pipeline (sauf que forcément dans ce cas faut changer de nom pour un nouveau car on peut pas péter l'existant en rajoutant args/data) Est-ce des gens qui connaissent peuvent aiguiller sur ce qui serait le plus propre à faire ?
rastapopoulos added the
compilo
APIs
amélioration
labels 11 months ago
b_b added this to the 4.1 milestone 11 months ago
Owner

Si il y a pas c'est surement parce qu'il y a des raisons profondes...

Rappelons donc les grands mécanismes :

  • la fonction recuperer_fond() produit d'abord le calcul du fond avec son contexte. (Si il y a un cache correspondant au fond+contexte il est directement utilisé) puis appelle le pipeline recuperer_fond sur le résultat

  • en conséquence, ce qui est ajouté à un fond via le pipeline recuperer_fond n'est pas dans le cache de SPIP, sauf éventuellement si l'appel du dessus est de la forme #INCLURE auquel cas le HTML issu de recuperer_fond() sera dans le cache de l'appelant

  • Pour la page principale, il y a mécanisme shortcut concernant le cache : il est directement stocké dans un nom qui ne dépend que de l'URL et des variables de contexte dans la query-string https://git.spip.net/spip/spip/src/branch/master/ecrire/public/assembler.php#L40
    Cela permet de retrouver le cache SANS accès à la base SQL et c'est donc un des gros atouts de SPIP en terme de performance et charge serveur

  • Si la page principale n'est pas en cache alors on va lancer la grosse artilerie, à savoir décoder l'URL pour avoir le contexte complet de la page
    https://git.spip.net/spip/spip/src/branch/master/ecrire/public/assembler.php#L108

En conséquence, pour toute page en cache il n'est pas possible de connaitre le contexte complet avec lequel est calculé le squelette racine sauf à renoncer à un point perfo essentiel de SPIP qui est d'être capable de servir les pages en cache sans connexion SQL

Il n'est donc pas possible de fournir un contexte dans tous les cas à affichage_final, et de ce fait la meilleure option est donc de n'en fournir aucun

Si il y a pas c'est surement parce qu'il y a des raisons profondes... Rappelons donc les grands mécanismes : - la fonction `recuperer_fond()` produit d'abord le calcul du fond avec son contexte. (Si il y a un cache correspondant au fond+contexte il est directement utilisé) puis appelle le pipeline `recuperer_fond` sur le résultat - en conséquence, ce qui est ajouté à un fond via le pipeline `recuperer_fond` n'est pas dans le cache de SPIP, sauf éventuellement si l'appel du dessus est de la forme `#INCLURE` auquel cas le HTML issu de `recuperer_fond()` sera dans le cache de l'appelant - Pour la page principale, il y a mécanisme shortcut concernant le cache : il est directement stocké dans un nom qui ne dépend *que* de l'URL et des variables de contexte dans la query-string https://git.spip.net/spip/spip/src/branch/master/ecrire/public/assembler.php#L40 Cela permet de retrouver le cache SANS accès à la base SQL et c'est donc un des gros atouts de SPIP en terme de performance et charge serveur - *Si* la page principale n'est pas en cache alors on va lancer la grosse artilerie, à savoir décoder l'URL pour avoir le contexte complet de la page https://git.spip.net/spip/spip/src/branch/master/ecrire/public/assembler.php#L108 En conséquence, pour toute page en cache il n'est pas possible de connaitre le contexte complet avec lequel est calculé le squelette racine sauf à renoncer à un point perfo essentiel de SPIP qui est d'être capable de servir les pages en cache sans connexion SQL Il n'est donc pas possible de fournir un contexte dans tous les cas à `affichage_final`, et de ce fait la meilleure option est donc de n'en fournir aucun
Poster
Owner

Alors je crois avoir à peu près tout compris de l'explication.

Cependant premier point : quand je vais sur une URL propre (donc qui n'a pas d'info "facile" à trouver quoi), et que je ne suis PAS en recalcul ni en calcul, et que j'ai déjà bien fait recalcul juste 2s avant donc tout est déjà fait et mis en cache : j'arrive bien à trouver les infos de "type-page" et de "id_article" dans $GLOBALS['page']['contexte'] notamment. Donc ça tendrait à dire qu'on a ces infos même quand ça va juste chercher le cache non ?

Ensuite deuxième point : si jamais ce n'est vraiment pas le cas certaines fois : ça me fait dire qu'il manque un truc dans ce qu'on récupère du cache du coup.
TOUT squelette, racine ou pas, est calculé avec un contexte (page, type-page, id_patate, dates, et tout autre var d'env), donc une fois en cache, quand on récupère, si on n'a pas ces infos sans traitement lourd en amont dès l'appel, ça veut dire qu'il FAUT pouvoir récupérer ce contexte de calcul dans le résultat du calcul, et non pas juste le PHP produit. Donc ce serait ça une des amélioration à apporter dans ce cas : que le cache enregistre et ressorte le PHP calculé ET le contexte/les variables d'environnement qui ont permis de le calculer. Et qu'on les fournisse proprement sans avoir à les chercher.

Mais donc d'abord le premier point : il me semble que j'ai bien type-page et id_XXX même sans calcul, avec le cache. Seulement il faudrait fournir ça plus proprement et officiellement, si on l'a bien tout le temps.

Alors je crois avoir à peu près tout compris de l'explication. Cependant premier point : quand je vais sur une URL propre (donc qui n'a pas d'info "facile" à trouver quoi), et que je ne suis PAS en recalcul ni en calcul, et que j'ai déjà bien fait recalcul juste 2s avant donc tout est déjà fait et mis en cache : j'arrive bien à trouver les infos de "type-page" et de "id_article" dans `$GLOBALS['page']['contexte']` notamment. Donc ça tendrait à dire qu'on a ces infos _même quand ça va juste chercher le cache_ non ? Ensuite deuxième point : si jamais ce n'est vraiment pas le cas certaines fois : ça me fait dire qu'il manque un truc dans ce qu'on récupère du cache du coup. TOUT squelette, racine ou pas, est calculé avec un contexte (page, type-page, id_patate, dates, et tout autre var d'env), donc une fois en cache, quand on récupère, si on n'a pas ces infos sans traitement lourd en amont dès l'appel, ça veut dire qu'il FAUT pouvoir récupérer ce contexte de calcul _dans le résultat du calcul_, et non pas juste le PHP produit. Donc ce serait ça une des amélioration à apporter dans ce cas : que le cache enregistre et ressorte le PHP calculé ET le contexte/les variables d'environnement qui ont permis de le calculer. Et qu'on les fournisse proprement sans avoir à les chercher. Mais donc d'abord le premier point : il me semble que j'ai bien type-page et id_XXX même sans calcul, avec le cache. Seulement il faudrait fournir ça plus proprement et officiellement, si on l'a bien tout le temps.
Poster
Owner

@jluc dit dans l'oreillette aussi, qu'avec son outil de visu du cache "xray", il voit que SPIP enregistre déjà le contexte lié et autres métadonnées en plus du PHP produit.

Donc à priori si j'ai suivi SPIP a bien tout sous la patte dans tous les cas : sans cache (calcul complet plus lourd) ou avec cache (récup depuis URL+query MAIS avec des métadonnées dont le contexte) : on a toujours les infos utiles à pouvoir transmettre aux pipelines finaux (variante de affichage_final par ex).

Qu'on ne puisse pas faire la proposition 1 de rationnaliser et avoir toujours recuperer_fond à la fin, à priori ça ok, pour avoir toujours ce système de cache différent rapide. Mais par contre une fois récupéré le cache et son contexte lié, là on doit pouvoir appeler affichage_final (ou plutôt une variante pour rien casser) avec du contexte cette fois.

@jluc dit dans l'oreillette aussi, qu'avec son outil de visu du cache "xray", il voit que SPIP enregistre déjà le contexte lié et autres métadonnées en plus du PHP produit. Donc à priori si j'ai suivi SPIP a bien tout sous la patte _dans tous les cas_ : sans cache (calcul complet plus lourd) ou avec cache (récup depuis URL+query MAIS avec des métadonnées dont le contexte) : on a toujours les infos utiles à pouvoir transmettre aux pipelines finaux (variante de affichage_final par ex). Qu'on ne puisse pas faire la proposition 1 de rationnaliser et avoir toujours recuperer_fond à la fin, à priori ça ok, pour avoir toujours ce système de cache différent rapide. Mais par contre une fois récupéré le cache _et son contexte lié_, là on doit pouvoir appeler affichage_final (ou plutôt une variante pour rien casser) _avec du contexte cette fois_.

En effet, sur 2 sites avec XRay, je vois que le cache des pages comporte un contexte complet. Disclaimer toutefois : ces sites n'utilisent pas d'url propres : les réécritures se font entièrement dans le htaccess.

Mais pour que le cache fonctionne, il faut bien qu'un premier calcul soit fait, et pour faire ce calcul, il faut nécessairement connaître le contexte. Et donc page ou pas, on peut enregistrer le contexte dans le cache quand on le crée. D'ailleurs il n'y a qu'une seule fonction d'enregistrement du cache, avec le contexte.

En effet, sur 2 sites avec XRay, je vois que le cache des pages comporte un contexte complet. Disclaimer toutefois : ces sites n'utilisent pas d'url propres : les réécritures se font entièrement dans le htaccess. Mais pour que le cache fonctionne, il faut bien qu'un premier calcul soit fait, et pour faire ce calcul, il faut nécessairement connaître le contexte. Et donc page ou pas, on peut enregistrer le contexte dans le cache quand on le crée. D'ailleurs il n'y a qu'une seule fonction d'enregistrement du cache, avec le contexte.
marcimat modified the milestone from 4.1 to 4.2 9 months ago
Sign in to join this conversation.
No Milestone
No project
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.