sur cette page http://www.maieul.net/-Qui-suis-je-
- je boucle sur des articles
- j'y appel #TEXTE et #NOTES
- chaque article à des notes de bas de page
du qui j'ai 2 renvois vers la note [1] qui sont des notes de bas de pages différents pour chaque article. Conséquent : j'ai plusieur fois des élements avec le même id. (exemple : id='nb1' ligne 188 et 212)
Sauf à numéroté à la main mes notes de bas de page, il n'y a pas moyen de corriger cela non ? Ne peut-on pas envisager une solution ?
La balise #NOTES, par définition, concerne une page et non les composants de la page,
il n'est pas normal de la mettre à l'intérieur d'une boucle sauf si on veut un effet
de page dans la page, auquel cas une numérotation manuelle est indispensable pour les distinguer.
Bref, ce n'est pas un bug.
Pas d'accord: normalement, on avait prévu (sauf pour ce coup des id) d'avoir de la souplesse dans l'affichage des notes, d'où la globale $compt_note, censée être réinitialisée quand on affiche les notes - de façon, explicitement, à pouvoir afficher successivement des séries de notes en recommençant à zéro.
Note, si on fait une présentation «façon blog», il est parfaitement logique de présenter quelques articles complets les uns à la suite des autres, sans rejeter l'affichage des notes tout en bas de page, mais à la fin de chaque article. Ça n'est pas un usage loufoque du truc, à mon avis.
Et il y a une foule d'usages qu'on peut imaginer, sans tomber dans le farfelu. Par exemple, afficher côté à côté un article et sa traduction - on ne souhaite alors pas mélanger leurs notes.
Une globale n'est jamais souple car elle interdit la réentrance. Il y a maintenant une fonction calculer_notes avec une interface précise permettant de faire tout ce qu'on veut. Il ne s'agit pas d'être d'accord ou pas, il s'agit de comprendre l'interface: #NOTES écrit tout ce qu'elle et se remet à 0. Si on veut l'appeler plusieurs fois par pages en ayant des noms de notes différenciés, il est inévitable de donner soi-même les numéros.
Pas d'accord non plus. Je n'avais pas repéré cette cassure, mais en
effet c'était programmé de manière à ce que, sur un blog, on puisse
afficher les notes de chaque article sans faire de mélanges affreux.
Il ne s'agit pas seulement de compatibilité ascendante, mais de
logique de publication (qui ici se heurte à la "logique informatique",
mais enfin il faut savoir quelle est la priorité d'un "système de
publication").
Je répète qu'il ne s'agit pas d'une quelconque "logique informatique" mais,
une fois de plus, de specs non précisées qui font que, lorsqu'un bug a été détecté
à propos de ces notes, ca a été réparé avec une autre spec en tête.
Surtout que je doute qu'il y ait casse et qu'il manque un test, car j'ai passé du temps dessus avant la release 2.1, en complétant notamment les tests.
Les appels consécutifs à #NOTES incrémentent un compteur qui préfixe le numéro, tout cela est parfaitement pris en compte, spécifié, implémenté, et testé.
Qui a vraiment vérifié la présence d'un bug avant de troller ?
- le problème des<INCLURE> n'avait jamais été traité, en particulier, si deux<INCLURE> étaient calculés sur des hits différents, les notes ont toujours étaient mélangées depuis la nuit des temps, ce qui obligeait à faire un recalcul de la page pour que tout retombe bien ;
- j'ai intégré dans la 2.1 une gestion du pointeur de #NOTES dans le cache des squelette, qui permet de le faire fonctionner même lorsque des<INCLURE> génèrent des #NOTES, en étant calculés à des hits différents ;
- Maieul ne nous dit pas quelle version de SPIP il utilise, et ne fournit aucune indication sur son squelette. Il faudrait peut-être commencer par là, non ?
Cédric
a oki bon mea culpa, donc il y a chaque fois c'est une 2.1.0[15604] avec un squelette perso Z.
En gros j'ai
<code>
<BOUCLE_articles(ARTICLES){id_rubrique} {par num titre}>
<INCLURE{fond=inclure/article_direct}{id_article}>
</BOUCLE_articles>
</code>
et dans article/direct :
<code>
<BOUCLE_article(ARTICLES){id_article}>
<div id="article-#ID_ARTICLE" class="article">
<h2 class="h2[ (#EDIT{titre})]">#TITRE</h2>
[<div class="texte[ (#EDIT{texte})]">(#TEXTE)</div>]
[<div class="notes">(#NOTES)</div>]
<div class="meta-publi"><a href="#sommaire">Retour au sommaire de la page</a></div>
</div>
</BOUCLE_article>
</code>
La compilation de la balise #NOTES consiste à ecrire les notes courantes et à remettre son compteur à 0.
Cela n'a pas changé depuis SPIP 1.7.2 au moins.
Je confirme donc qu'il n'y a donc aucune cassure.
En revanche, pour un cas comme le tien, on peut envisager que cette balise prenne un argument signifiant qu'il ne faut pas remettre le compteur à 0, mais c'est du taf.
étrangement en local cela ne le fait pas... donc la modif de cerdic doit le faire. il doit avoir un bizn dans mon install SPIP, pourtant c'est du tout neuf.
Ah mais je m'insurge et je précise :
- les specs sont parfaitement claires, contrairement à ce qui a été dit ici ;
- elles sont toutes implémentés, jusqu'à preuve du contraire ;
