Typiquement si : `<BOUCLE_a(ARTICLES){id_secteur=1}{id_?}>` alors le critère `{id_?}` j’ajoutera pas `{id_secteur?}`
L’ordre des critères est important (on ne s’occupe pas des critères qui sont après `{id_?}` mais bien de ceux avant).
Ces commentaires sont ajoutés dans le commentaire déjà existant qui précède le code php de la boucle (qui indiquait déjà le nom de la boucle et ses critères).
On utilise cela dans le critère id pour lister, en mode debug, les champs utilisés par le critère.
Ça permet de vérifier la magie. Et potentiellement de servir à d’autres critères.
À toutes fins utiles, on ajoute aussi un modificateur, avec la liste des champs dedans.
(cas des tables de liens, mais aussi de spip_forum) et dans ce cas on considère qu’elle est associable avec tous les objets (et donc, pour spip_forum, on retourne
aussi le champ id_rubrique, entre autres).
Pour ce faire, et après quelques discussions, on introduit un critère `{id_?}`.
Ce critère, va en quelque sorte s’expanser en autant de critères conditionnels `{id_article?}{id_rubrique?}...` adaptés à la boucle en question.
Ce critère sera très pratique dans les squelettes de listes d’objets filtrables.
On calcule la liste des champs à insérer avec la fonction lister_champs_selection_conditionnelle() (qui peut être altérée par le pipeline du même nom).
Ces champs sont :
- tous les champs id_xxx de la table de la boucle. (id_article, id_rubrique, id_secteur, id_trad pour la boucle ARTICLES)
- le champ 'objet' de la table de la boucle si elle en a un (par exemple dans la boucle FORUMS)
- les champs id_xxx clés primaires de tables qui peuvent être liées facilement à cette table (par exemple avec une table de liaison).
YEAR("2002-09-24 16:28:00")-YEAR(articles.date) = ''
au lieu de
YEAR("2002-09-24 16:28:00")-YEAR(articles.date) = 0
Le premier marchant en mysql mais pas en sqlite
(Par contre un {annee_relatif=0} marchait bien dans tous les cas)
Ainsi le tri `(ARTICLES){par sinum titre, num titre, titre}` va trier : d'abord les articles avec numéros, puis les numéros croissants, puis les titres croissants.
Pour rappel, l'écriture seule `(ARTICLES){par num titre, titre}` va trier : d'abord les articles sans numéros (ils ont le numéro 0), puis les articles avec numéros
croissants, puis les titres croissants.
Cette expression ne s'occupe pas de la valeur des numéros. si le champ a un numéro différent de 0, le SELECT 'sinum' vaut 1, sinon (numéro 0 ou pas de numéro)
sinum vaut 1, ce qui fait que le tri {par sinum} croissant met les 0 ou sans numéros en dernier..
- les expressions telles que `{par num titre}` ou `{par multi titre}` sont extensibles. `{par expr champ}` cherchera une fonction
`calculer_critere_par_expression_{expr}` pour gérer cette expression
- une fonction `calculer_critere_par_champ()` est utilisée pour retrouver la table de tri d'un champ demandé.
Cette fonction est d'ailleurs aussi utilisée par les fonctions `num` ou `multi`.
Cela harmonise un peu les diverses utilisations entre ces 3 cas principaux `{par x}{par num x}{par multi x}`.
x peut être :
- un champ de la table (titre),
- un champ dont la table de jointure est nommé (documents.titre),
- un champ dont l'alias de table est nommé (L1.titre) (à éviter, surtout là pour compat)
- un champ d'exception de jointure (titre_mot)
- un champ d'une autre table dont la jointure est explicite (ARTICLES documents){par taille}
- un champ d'une autre table dont la jointure est possible (DOCUMENTS){par rang_lien}
Le changement est que si la jointure existe déjà pour un champ, le champ sera correctement préfixé de l'alias de table correspondant,
et dans certains cas une nouvelle jointure ne sera pas créé inutilement.
Entre autres :
- `(DOCUMENTS){id_article?}{id_rubrique?}{vu=non}{par rang_lien}`, le ORDER BY de rang_lien est bien préfixé de l'alias d'une table de jointure.
Il ne peut plus y avoir d'ambiguité sur le champ, rapporté par Mysql si la table de jointure est présente 2 fois. Cependant le ticket #3894 reste entier.
L'instruction COLLATE doit s'incrire dans le ORDER BY avant un éventuel ASC ou DESC.
Cette possibilité était déjà prévue dans le critère `{par}` lorsque le critère `{collate}` est placé avant lui (il s'applique à tous les `{par}` suivants)
mais le test de modificateur avait une coquille de nommage qui ne correspondait pas à celui créé dans le critère collecte, donc `{collecte xxx}{!par titre}`
ne fonctionnait pas.
Inversement, lorsqu'on ajoutait l'instruction sur le précédent critère `{par}`, comme dans `{!par titre}{collecte xxx}`, l'instruction se plaçait après DESC
ce qui créait une erreur SQL.
avec une jointure sur id_rubrique créait toujours une jointure
même si id_rubrique n'était pas présent dans l'environnement.
On transmet le type de champ attendu à l'appel de sql_quote pour réparer.
en r4605 qui ajoutait la compilation des critères `{a,b}` ou `{n-a,b}` ou `{a, n-b}`
avec a ou b dynamiques. Le cas `{n-#GET{nb}, 5}` devrait mieux se passer.
- encoding (utf8)
- eof_ending (saut le ligne en fin de fichier)
- elseif (pas else if)
- function_call_space (espaces sur fonctions)
- function_declaration (pareil)
- function_typehint_space (pareil)
Evolution de la syntaxe du critère pagination.
On privilégie maintenant l'écriture suivante {pagination 10, nom} plutôt que l'ancienne syntaxe {pagination 10 nom} sans virgule qui ne fonctionnait pas toujours (i.e. {pagination 10 x}).
L'ancienne syntaxe est conservée pour assurer la compatiblité ascendante mais est maintenant déconseillée.
marcimat@rezo.net
