Re: SPIP nu

Le 25/05/2016 22:01, James a écrit :
> J'admets que la solution que je propose n'est pas la panacée. Et je veux
> bien temporiser pour la recherche d'une solution permettant de nous
> débarrasser des verrous techniques qui empêchent d'isoler les plugins du
> core, et le core de certains plugins et de permettre de proposer des
> distributions, etc...
>
> Donc, la question, c'est : "comment simplifier l'interface de
> programmation pour permettre ce genre de besoin ?" et le corrolaire :
> "où est-ce que ça se code ?"

Bah moi je trouve ça plutôt très bien ce que tu as commencé. Il me 
manque juste l'info de fond dans Boucle (voire d'autres infos si on a, 
la composition, etc) et je ne vois pas ce qui manquerait.

De ce que j'ai compris par rapport à {where} c'était pas pour rentrer 
dedans et modifier des choses comme pour ce qui était prévu avec 
{pipeline} au départ. C'était se baser sur TON pipeline en testant si 
{where} étant présent dans les critères et ajoute {id_mot?} dans ce cas. 
Ce qui n'est pas du tout pareil. Mais peut-être ai-je mal compris.

Sinon, autant je comprends que se baser sur le chemin du fichier peut 
être bancal et pas pérenne. Autant se baser sur le fond, je vois pas 
pourquoi ce ne serait pas pérenne. C'est exactement comme 
recuperer_fond() quand un plugin ajoute des choses dans un squelette 
*après coup*. Sauf que là on ajoute des choses *avant*. Mais en se 
basant sur tels et tels fonds demandés aussi.

Mais pour le cas précis de {id_mot?},  vu que c'est une table de lien 
générique, oui, ça peut évidemment être bien de se baser sur la présence 
d'un truc plus commun que tels fonds précis, ce qui permet alors 
d'ajouter le critère aussi sur un objet "patates" qui aurait sa liste 
d'admin.

-- 
RastaPopoulos