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

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
> 

----
[email protected] - https://listes.rezo.net/mailman/listinfo/spip-zone