Re: SPIP nu

Yo,

Le 25 mai 2016 à 15:41, Cédric Morin <[email protected]> a écrit :

> Hello,
>
>
> Les listes du core qui ont un {id_mot?} ont aussi toutes (ou presque) un
> {where?} sorte de critère fourre tout qui a pour but de pouvoir
> personnaliser les filtres en passant une condition supplémentaire en
> argument de l'inclusion.
>
> Est-ce qu'il ne vaudrait pas mieux prendre ce {where?} existant en
> convention et simplement que le plugin mots rajoute son critere
> conditionnel {id_mot?} sur les boucles qui ont ce critere {where?} ?
>

Qu'il s'appelle {where} ou {pipeline}, le problème ne change pas. C'est un
critère qui, au moment où on en fait une requête SQL, l'objet Boucle est
déjà passer par le phraseur, on ne peut donc pas, sauf bidouille extrême,


>
> Il me semble périlleux de se baser sur le nom du fond ou de la boucle pour
> ajouter un critère automatiquement à une boucle, je crains qu'on ait des
> effets de bord mal maitrisés.
>

En effet. On peut comparer ce type de test à la manière dont il faudra
coder un Critere tel que c'est possible actuellement, sans casser la
compatibilité ascendante ni réécrire totalement le compilateur, ou à
l'imbrication de tableau associatif qu'il faut maîtriser pour coder
certains pipelines aujourd'hui et évaluer les périls un à un, on ne règlera
pas la question de quand insérer un critère ou pas dans une boucle et sous
quelles conditions :P

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 ?"


>
> --
> Cédric
>
>
--
James