Re: [Spip-zone-commit] r114271 - in _core_/plugins/mots

Re,

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.

Bref, à mettre au point :)

--
Cédric
Le 3 mars 2019 à 09:36 +0100, Matthieu Marcillaud <[email protected]>, a écrit :
> Hello :)
>
> 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.
>
> MM.
>
>
>
> Le 03/03/2019 à 02:48, Cerdic a écrit :
> > Hello Touti,
> >
> > 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)
> >
> > Bises
> >
> > --
> > Cédric
> > Le 2 mars 2019 à 19:21 +0100, [email protected], a écrit :
> > > Author: [email protected]
> > > Date: 2019-03-02 18:21:41 +0000 (Sat, 02 Mar 2019)
> > > New Revision: 114271
> > >
> > > Added:
> > > _core_/plugins/mots/prive/objets/liste/articles-mot.html
> > > _core_/plugins/mots/prive/objets/liste/articles-mot_fonctions.php
> > > _core_/plugins/mots/prive/objets/liste/rubriques-mot.html
> > > Modified:
> > > _core_/plugins/mots/paquet.xml
> > > _core_/plugins/mots/prive/squelettes/contenu/mot.html
> > > Log:
> > > Création des fichiers qui listent les articles et les rubriques d'un mot
> > > dans l'espace privé.
> > >
> > > Duplication de ceux du core, deviennent articles-mot et rubriques-mot.
> > >
> > >
> > > Details: https://zone.spip.org/trac/spip-zone/changeset/114271
> > >
> > > _______________________________________________
> > > [email protected] -
> > > https://listes.rezo.net/mailman/listinfo/spip-zone-commit
> >
>
>
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip