je comprend bien l’objectif poursuivi, mais ça semble un peu brutal et pas très satisfaisant de forker les squelettes listes articles/rubriques, car du coup ceux qui les ont personnalisés perdent des morceaux, et cela pose aussi plusieurs questions de généricité :
Ce que tu fais ici pour les mots, faut il le faire pour tout objet qui vient enrichir les articles ?
Et dans l’autre sens tu as changé le nommage générique en demandant donc une liste {table}-mot pour les autres objets ne faisant pas partie du core.
Donc on casse plein de compat sur les objets perso, mais au delà est il raisonnable de se retrouver à dupliquer des listes ad-nauseam partout ?
Pour le moment c’était resté comme ça car il n’a jamais été considéré comme critique de se débarasser de ce {id_mot?} dans ces listes, mais si on veut vraiment se débarasser de la dépendance je pense qu’on doit faire mieux que ça en évitant tous ces dédoublement.
Une solution à laquelle je pense serait de faire un critère spécifique genre {selection_conditionnelle} (nomenklatura si tu as mieux on prend !) qui regarderait les id_xxx connus dans l’environnement et pour chaque chercherait une fonction du type inc_generer_condition_selection_{id_xx}_dist qu’on appelerait sur le mode
$generer_condition_selection = charger_fonction(‘generer_condition_selection_’.$primary,’inc’);
$boucle->where[] = $generer_condition_selection($type_boucle,champ_sql($primary));
a charge pour chaque plugin de déclarer la fonction de selection correspondante et d’y gerer tous les cas (ici si pas de $_PILE[0][‘id_mot’] ça renvoie un 1=1)
Bref, c’est juste les grandes lignes, il y a surement des problèmes à résoudre et de la mise au point à faire, mais ça me semble une direction plus générique et souhaitable pour à la fois résoudre la dépendance de ces listes d’un plugin en particulier et éviter de faire 36 copies dans tous les coins de la zone…
(en évitant de la rupture de compat, puisque les surcharges continueraient de fonctionner, de même que les listes existantes d'autres objets éditoriaux)
Je réponds aussi, puisqu’on en a un peu parlé IRL en même temps, et cette solution était le plus simple à mettre en œuvre. Mais effectivement c’est embêtant.
Il y a 2 ans, James proposait de passer par un pipeline permettant d’étendre le contenu du texte des critères (au niveau du phraseur) pour insérer "{id_mot?}", mais cela a aussi des problématiques.
Ce que tu proposes là me parait aussi intéressant et plus générique, quoi que plus difficile à coder. J’essaierai d’y jeter un œil tout de même.
A la faveur de la nuit, je me dis que le plus simple serait même que le critère prendrai les clés primaires connues et ferait un foreach dessus en se compilant comme en suite de {id_xx?}
Ça doit pouvoir se faire assez simplement.
Et dans un second temps on pourrait même passer en argument des clés à ignorer
{selection_conditionnelle !id_rubrique,!id_auteur}
-> dans ce cas ça prend toutes les clés connues sauf celle exclues si on les rencontre
ou lister explicitement les clés qu’on veut utiliser
{selection_conditionnelle id_auteur,id_mot}
-> dans ce cas ça ne prend que les clés connues dans cette liste
Syntaxe à affiner évidemment, mais par contre ça ne pourrait être qu’une liste statique, connue au moment de la compilation
(dans ce cas pas de #LISTE{…} ou de #GET ou de #ENV), mais ça me paraît pas rédibhitoire et ça pourrait coller au besoin
Et aussi à tester sur des cas réels avec des grosses bases d’articles pour voir si ça fait pas des requêtes qui explosent…
Si c’est pas viable, l’option des fonctions qui fourniraient des where semble une alternative, au risque de faire une liste de sql_in(‘id_article’,…) avec des très grosses listes.
Et enfin en dernière option, les fonctions s’enchainent pour se passer la liste d’id_article, qu’elles réduisent une par une par intersection en fonction de leur requête.
Ça permet d’enchainer plusieurs requetes plus simples et de finir avec un seul id_article IN (…) avec potentiellement une liste plus courte.
Sur les grosses bases c’est moins couteux que les jointures qui multiplient le nombre de ligne en résultat de la requête.
Très embêtant.
Devoir dupliquer tous les squelettes d'objets éditoriaux me parait une fausse bonne idée, je suis sûr qu'on peut trouver quelque chose de beaucoup plus smart
Je dis ça sans y avoir réfléchi plus que ça, mais dans plugins/mots/prive/squelettes/contenu/mot.html, dans la BOUCLE_autresobjets, on pourrait construire un #ARRAY des objets en récupérant leur champ titre et leur clé primaire, et passer ce tableau à un prive/objets/liste/objets-mot.html générique qui bouclerait dessus.
Tel que proposé actuellement, (ARTICLES){selection_conditionnelle}...
va ajouter sur la boucle :
- tous les {id_xx?} présents sur spip_articles (id_article, id_rubrique, id_secteur, id_trad)
- tous les {id_xx?} correspondants à des clés primaires des objets éditoriaux éditables (id_auteur, id_mot, id_groupe, id_message, id_syndic, id_breve, id_document) avec les plugins dist par défaut.
Ça fait quand même beaucoup de conditions théoriques et de calculs de jointures potentielles, même si elles ne sont finalement pas utilisées.
En tout cas ça répond à la problématique pour prive/objets/liste/{objet}.html et son usage il me semble.
Tel que proposé actuellement, (ARTICLES){selection_conditionnelle}...
va ajouter sur la boucle :
- tous les {id_xx?} présents sur spip_articles (id_article, id_rubrique,
id_secteur, id_trad)
Ah oui ceux-là aussi il faut les mettre, je n’y avais pas pensé
- tous les {id_xx?} correspondants à des clés primaires des objets
éditoriaux éditables (id_auteur, id_mot, id_groupe, id_message,
id_syndic, id_breve, id_document) avec les plugins dist par défaut.
Du coup sur ça en y reflechissant je pense qu’il faudrait ne prendre que les id_x qui remplissent une des conditions suivantes
* id_x est un champ de la table sur laquelle la boucle porte (articles ici) -> mais du coup c’est pris en compte avec ta condition précédente
* la table x contient un champ id_article (ici, à apadapter en fonction de la boucle)
* il existe une table x_lien
Ce qui réduirait quand même déjà les combinatoires sans aucun sens ( {id_breve?} sur une table article n’a pas de sens)
Ensuite on peut dire que cette liste de clé automatique pour la table (articles) passe dans un pipeline, ce qui permet éventuellement aux plugins d’ajouter des cas particuliers qui sortent de ces critères là, ou au contraire de retirer un id_x qui n’a pas de sens
Et enfin on ajoute tous les {id_x?} en critère sur la boucle
Ça fait quand même beaucoup de conditions théoriques et de calculs de
jointures potentielles, même si elles ne sont finalement pas utilisées.
En tout cas ça répond à la problématique pour
prive/objets/liste/{objet}.html et son usage il me semble.
En effet là je pense qu’on peut déjà avoir une version qui marche et qui remplace notre {id_mot?} bancal sans duplication de code, à affiner selon les cas problématiques que l’on rencontrera ensuite
Merci Touti pour la correction qui évite déjà la création d’un squelette liste/xxxx-mot.html sur tous les objets éditoriaux, c’est toujours ça de pris.
Ensuite je ne doute pas en effet que ceux qui ont déjà personnalisé les squelettes sachent s’en sortir, mais si on peut éviter de devoir dupliquer des squelettes de l’espace privé autant que possible ça sera toujours beaucoup mieux
