voila, je vous soumets mon probleme qui est peut être un bug de [(#TYPE|unique)],
(ça ne doit pas avoir d'influences que ce soient sur des docs plutot que sur des articles)
dans un modele inclus dans un squelette, une boucle documents appelle
[(#MODELE{mots-doc}{id_document})]
dans modeles/mots-doc.html
<BOUCLE_archi(MOTS){type=architecte}{id_document}{', '}>
[(#TYPE|unique):]<a href="#URL_MOT" class="spip_url">#TITRE</a>
</BOUCLE_archi>
hors, je ne vois apparaitre le type 'architecte' que dans le premier document
et un [(#TOTAL_BOUCLE|unique) testunique] retourne bien à chaque document testunique
hors, je ne vois apparaitre le type 'architecte' que dans le premier
document
Il y a un problème connu avec |unique et les inclusions (ou les modèles,
c'est pareil) : ils ne sont pas remis à zéro à chaque inlure, et sont donc
"partagés" entre tous les caches calculés lors d'un même hit. C'est possible
de le corriger, avec probablement un peu de conséquence en termes de
performances.
hors, je ne vois apparaitre le type 'architecte' que dans le premier document
Il y a un problème connu avec |unique et les inclusions (ou les modèles,
c'est pareil) : ils ne sont pas remis à zéro à chaque inlure, et sont donc
"partagés" entre tous les caches calculés lors d'un même hit. C'est possible
de le corriger, avec probablement un peu de conséquence en termes de
performances.
Ah ben alors, justement ce qui manque avec les doublons...
?
JLuc
> Il y a un problème connu avec |unique et les inclusions (ou les modèles,
> c'est pareil) : ils ne sont pas remis à zéro à chaque inlure, et sont donc
> "partagés" entre tous les caches calculés lors d'un même hit. C'est possible
> de le corriger, avec probablement un peu de conséquence en termes de
> performances.
Ah ben alors, justement ce qui manque avec les doublons...
?
Non, non, c'est bien un bug, car c'est les caches *calculés* lors du même
hit qui partagent. Si un cache est pris dans le cache, et un autre est
calculé, ils ne partagent plus.
> Il y a un problème connu avec |unique et les inclusions (ou les
modèles,
> c'est pareil) : ils ne sont pas remis à zéro à chaque inlure, et sont
donc
> "partagés" entre tous les caches calculés lors d'un même hit. C'est
possible
> de le corriger, avec probablement un peu de conséquence en termes de
> performances.
Ah ben alors, justement ce qui manque avec les doublons...
?
Non, non, c'est bien un bug, car c'est les caches *calculés* lors du même
hit qui partagent. Si un cache est pris dans le cache, et un autre est
calculé, ils ne partagent plus.
Mais comment peut-on deviner, dans le filtre, qu'on passe d'un cache à un
autre ?
> Non, non, c'est bien un bug, car c'est les caches *calculés* lors du même
> hit qui partagent. Si un cache est pris dans le cache, et un autre est
> calculé, ils ne partagent plus.
Mais comment peut-on deviner, dans le filtre, qu'on passe d'un cache à un
autre ?
Je suppse que, quand on commence à calculer un nouveau cache, on pourrait
appeler unique(NULL,NULL,'tout vider') qui ferait un reset de la mémoire ?
Non, non, c'est bien un bug, car c'est les caches *calculés* lors du même
hit qui partagent. Si un cache est pris dans le cache, et un autre est
calculé, ils ne partagent plus.
Mais comment peut-on deviner, dans le filtre, qu'on passe d'un cache à un
autre ?
Je suppse que, quand on commence à calculer un nouveau cache, on pourrait
appeler unique(NULL,NULL,'tout vider') qui ferait un reset de la mémoire ?
Et inversement / ou similairement,
ne pourrait il y avoir un mécanisme
qui mette de même à zero une liste de doublons,
ce qui ferait que cette liste ne serait pas remise à zéro
par la suite globalement dans spip
jusqu'à nouvel ordre
(et contrairement au fonctionnement par défaut)
Il y a un problème connu avec |unique et les inclusions (ou les modèles,
c'est pareil) : ils ne sont pas remis à zéro à chaque inlure, et sont donc
"partagés" entre tous les caches calculés lors d'un même hit. C'est possible
de le corriger, avec probablement un peu de conséquence en termes de
performances.
Oui, on pourrait considérer ça comme un 'bug'... Ou un 'feature' !
En fait, j'ai passablement tiré partie de cette 'particularité' dans le jeu
de squelettes Alternatives, notamment pour les menus contextuels des
langues. Ça m'embêterait que ce comportement (ou bug) soit modifié ou
corrigé. Il faudrait revoir bon nombre de sites...
> Il y a un problème connu avec |unique et les inclusions (ou les modèles,
> c'est pareil) : ils ne sont pas remis à zéro à chaque inlure, et sont donc
> "partagés" entre tous les caches calculés lors d'un même hit. C'est possible
> de le corriger, avec probablement un peu de conséquence en termes de
> performances.
Oui, on pourrait considérer ça comme un 'bug'... Ou un 'feature' !
Euh, non, c'est un bug. Un squelette qui en appelle un autre, à moins
d'avoir des délais 0, ne sait pas s'il va taper dans le cache ou pas...
En fait, j'ai passablement tiré partie de cette 'particularité' dans le
jeu de squelettes Alternatives, notamment pour les menus contextuels des
langues.
Ce n'est pas un bug fiable, désolé
Ça m'embêterait que ce comportement (ou bug) soit modifié ou corrigé.
C'est bien la première fois que je lis une chose pareille
constaté en [8282] (avec et sans plugins) avec FF 2.0.1 :
au moment de la fin du chargement de la page le navigateur se bloque
quelques secondes puis enfin affiche la page. Typiquement un script
js sur le onload qui mouline plein de récurences puis se termine après
quelques instants ou un gros fichier de syndication qui se charge
quand on affiche une prévisualisation d'un flux RSS et qu'il y a plein de
choses à calculer par le navigateur.
$ is not defined
[Break on this error] $(document).ready(function(){
dans /ecrire/ ligne 28 dont voici la source :
<script type="text/javascript"
src="../dist/javascript/presentation.js"></script>
26
27 <script type="text/javascript"><!--
28 $(document).ready(function(){
29 verifForm();
30 $("#page")
31 .mouseover(function(){
32 changestyle("garder-recherche");
33 });
mais pas sûr que ça soit lié à ce temps de latence bizarre
A bientôt
