Naïvement, j'avais pensé que #INCLURE ne provoquait pas l'écriture d'un cache pour l'élément inclus puisque ce dernier était placé en inline à l'intérieur de l'élément incluant.
Mais je viens de faire un squelette de test minimaliste qui m'a permis de me rendre compte que la production de fichiers en cache était sensiblement identique que j'utilise <INCLURE> ou #INCLURE
Donc :
- est-ce que c'est un bug que le squelette inclus par #INCLURE provoque la création d'un cache ?
- si ce n'est pas un bug, pourquoi donc ?
Naïvement, j’avais pensé que #INCLURE ne provoquait pas l’écriture d’un cache pour l’élément inclus puisque ce dernier était placé en inline à l’intérieur de l’élément incluant.
Mais je viens de faire un squelette de test minimaliste qui m’a permis de me rendre compte que la production de fichiers en cache était sensiblement identique que j’utilise ou #INCLURE
Donc :
est-ce que c’est un bug que le squelette inclus par #INCLURE provoque la création d’un cache ?
non, c’est une fonctionnalité
si ce n’est pas un bug, pourquoi donc ?
c’est la spec qui a été définie comme cela.
Le comportement que tu voudrais correspond à celui des #MODELE
Dans la pratique, une meme inclusion peut être utilisée plusieurs fois sur un hit, et ne sera calculée qu’une fois.
Cédric
Naïvement, j'avais pensé que #INCLURE ne provoquait pas l'écriture d'un cache pour l'élément inclus puisque ce dernier était placé en inline à l'intérieur de l'élément incluant.
Mais je viens de faire un squelette de test minimaliste qui m'a permis de me rendre compte que la production de fichiers en cache était sensiblement identique que j'utilise <INCLURE> ou #INCLURE
Donc :
- est-ce que c'est un bug que le squelette inclus par #INCLURE provoque la création d'un cache ?
- si ce n'est pas un bug, pourquoi donc ?
Je relis la doc #INCLURE en statique
La version SPIP 1.9.1 a introduit une autre méthode d’inclusion : #INCLURE.
La syntaxe <INCLURE{fond=..}> provoque l’inclusion des pages à chaque visite d’un internaute, que celle-ci concerne une page déjà en cache ou non.
Avec la nouvelle balise [(#INCLURE{fond=...})], l’inclusion est réalisée lors du calcul du squelette, et son résultat est stocké dans le cache de la page appelante. Avec ce système, on ne peut plus gérer une durée de vie ($delais ou #CACHE{}) réduite pour un squelette inclus ; en revanche il devient possible d’appliquer des filtres sur le squelette inclus : [(#INCLURE{fond=lettre}|version_texte)].
<INCLURE{fond=..}> et [(#INCLURE{fond=..})] ont donc des fonctionnements différents :
— avec <INCLURE{fond=..}>, chaque squelette inclus a un cache indépendant ;
— avec [(#INCLURE{fond=..})], la page principale appelante contient, en cache, l’intégralité du code généré, et les fichiers inclus n’ont pas de cache séparé.
, et d'après la doc : "et les fichiers inclus n’ont pas de cache séparé."
un bug de la doc, alors, que je peux t’assurer que cela n’a jamais été fait ni prévu comme cela.
Cette affirmation de la doc est par contre vraie pour les modeles.
Naïvement, j'avais pensé que #INCLURE ne provoquait pas l'écriture d'un
cache pour l'élément inclus puisque ce dernier était placé en inline à
l'intérieur de l'élément incluant.
Mais je viens de faire un squelette de test minimaliste qui m'a permis de
me rendre compte que la production de fichiers en cache était sensiblement
identique que j'utilise <INCLURE> ou #INCLURE
Donc :
- est-ce que c'est un bug que le squelette inclus par #INCLURE provoque la
création d'un cache ?
non, c'est une fonctionnalité
- si ce n'est pas un bug, pourquoi donc ?
c'est la spec qui a été définie comme cela.
Donc, la doc qui dit : "et les fichiers inclus n’ont pas de cache séparé." est fausse ?
, et d'après la doc : "et les fichiers inclus n’ont pas de cache séparé."
Donc, c'est un bug...
La doc n'est pas une doc technique mais une doc "créateur de squelette"
donc "pas de cache séparé" ça veut pas forcément dire "pas de fichier de cache"
mais peut être seulement "pas de fonctionnement de cache autonome".
> Cette affirmation de la doc est par contre vraie pour les modeles.
Quel que soit leur forme d'appel ?
>je sais pourquoi j'ai 140 000 fichiers dans le cache
Pourquoi ? C'est pas évident qu'une inclusion "à part"
prenne plus de place qu'une inclusion "inline" (?)
, et d'après la doc : "et les fichiers inclus n’ont pas de cache séparé."
Donc, c'est un bug...
La doc n'est pas une doc technique mais une doc "créateur de squelette"
donc "pas de cache séparé" ça veut pas forcément dire "pas de fichier de cache"
mais peut être seulement "pas de fonctionnement de cache autonome".
> Cette affirmation de la doc est par contre vraie pour les modeles.
Quel que soit leur forme d'appel ?
>je sais pourquoi j'ai 140 000 fichiers dans le cache
Pourquoi ? C'est pas évident qu'une inclusion "à part"
prenne plus de place qu'une inclusion "inline" (?)
D'après mes tests, c'est plus gros si ce qui est inclus est petit :
<li><a href="Au-fait/Formulaire">Formulaire</a></li>
";s:9:"squelette";s:37:"html_ed04161a9773ae770ee92dd69bd1422d";s:6:"source";s:41:"sites/dev.sc/squelettes/noisettes/it.html";s:11:"process_ins";s:4:"html";s:11:"invalideurs";a:1:{s:5:"cache";s:35:"2/noi-t-2009_03_27%2014%3A-38f04f2d";}s:7:"entetes";a:1:{s:12:"X-Spip-Cache";i:2592000;}s:5:"duree";i:0;s:8:"contexte";a:7:{s:4:"page";s:1:"t";s:4:"date";s:19:"2009-03-27 14:24:14";s:12:"date_default";b:1;s:10:"date_redac";s:19:"2009-03-27 14:24:14";s:18:"date_redac_default";b:1;s:10:"id_article";s:2:"16";s:4:"lang";s:2:"fr";}s:2:"gz";b:0;}