[spip-dev] Suggestion/idée pour le critère {fusion}

Dev
1

Une raison pour utiliser le critère {fusion} est de vouloir compter les éléments fusionnés -- un SQL COUNT(*) ... GROUP BY

Serait-il possible d'étendre le critère {fusion} pour qu'une balise de compteur soit dispo à l'intérieur d'une boucle qui porte ce critère ?

Paolo

2

Une raison pour utiliser le critère {fusion} est de vouloir compter les éléments fusionnés – un SQL COUNT(*) … GROUP BY

Serait-il possible d’étendre le critère {fusion} pour qu’une balise de compteur soit dispo à l’intérieur d’une boucle qui porte ce critère ?

#COMPTEUR_BOUCLE et #TOTAL_BOUCLE ne te conviennent pas ou ne fonctionnent pas?

Paolo

kent1

3

Pour avoir, en SPIP, cette requête SQL simple :

SELECT lang, COUNT(*) FROM `trad_lang` GROUP BY lang

il faut (je pense) écrire une double boucle :

<BOUCLE_a(trad_lang){fusion lang}>
#LANG<BOUCLE_count(trad_lang){lang=#LANG} /> #TOTAL_BOUCLE <br
/><//B_count>
</BOUCLE_a>

je peux tout à fait vivre avec :wink:
il me semble juste étrange que ce COUNT(*) est inaccessible directement.

Paolo

4

Il y a la balise de Renato #EXPRESSION{COUNT(id_article)} :

http://zone.spip.org/trac/spip-zone/browser/plugins/agregateurs_sql/doc.txt

BoOz

Paolo wrote:

5

* Paolo tapuscrivait, le 07/05/2010 20:03:

Une raison pour utiliser le critère {fusion} est de vouloir compter les
éléments fusionnés -- un SQL COUNT(*) ... GROUP BY

Serait-il possible d'étendre le critère {fusion} pour qu'une balise de
compteur soit dispo à l'intérieur d'une boucle qui porte ce critère ?

Même si c'est pas fait pour, {pagination 1} et #GRAND_TOTAL
Utilisé dans Connexion · GitLab

-- RealET

6

Tiens, mais oui, c'est exactement cela !
merci, je vais regarder.

Paolo

7

Et oui !

Cette balise c'est ni plus ni moins que le chainon manquant pour propulser spip dans la stratosphere des frameworks de génie.

Pourquoi ne pas l'intégrer cache moustache dans le core ? Et bien parce qu'il faut la tester, valider la syntaxe, et dérouiller le critère {fusion} de spip qui n'est pas encore optimisé pour les calculs statisitiques génériques (en gros il cale sur certains group by).

+ voir ce que ca donne sur autre chose que mysql.

BoOz, enthousiaste.

Paolo wrote: