[spip-dev] SPIP nu

Dev
1

Suite aux discussions de la zone sur son aménagement, juste comme ça, pour essayer, j’ai installé un spip sans plugins, un spip « nu » :

svn co --ignore-externals svn://trac.rezo.net/spip/spip spipnu

L’installation se passe bien, l’étape d’activation des plugins est bypassée proprement.

Une fois dans l’espace privé, bien sûr, c’est cassé :

3 erreurs de squelettes
…/prive/objets/liste/auteurs_enligne.html (a priori les critères imessage et en_ligne necessite organiseur)
…/prive/objets/liste/articles.html (le critère {id_mot?} n’est pas connu)
…/prive/themes/spip/theme.css.html fait appel à 2 filtres couleur_luminance et couleur_saturation du plugin filtres_images

En supprimant brutalement les critères imessage et en_ligne, id_mot? et les filtres, on arrive à une interface privée tout à fait acceptable.

Donc, sur le plan technique, il faudrait éventuellement trouver le moyen de contourner la dépendance à mots, organiseur et filtres_images et on a bel et bien un « noyau » SPIP indépendant des plugins-dist.

Sur le plan fonctionnel, c’est sans doute une autre histoire, il y a sans doute des choses à retirer par défaut (ex: Activité/Afficher les visiteurs, …)

Pour info, un petit tour dans les tables :

spip_meta |

La table technique

spip_articles |
spip_auteurs |
spip_auteurs_liens |
spip_rubriques |

La base éditoriale

spip_jobs |
spip_jobs_liens |

Le génie (cron) de SPIP n’est pas un plugin.

spip_resultats |

a priori, cette table-là serait obsolète ?

Je crois qu’il y a une démarche à trouver pour savoir ce qu’on doit garder dans le noyau, et ce qui peut passer en plugin et ceci en rendant le noyau vraiment indépendant du code et des fonctionnalités qui seront déplacées.

2

Hello,

3

Hello,

j’ai une idée pour les critères non reconnus qui sont liés aux plugins externes (je pense à {id_mot}).

Sous Linux, lorsqu’on lance une commande qui n’existe pas, on a généralement un simple plantage.

Mais sur Ubuntu, ils ont eu l’idée d’aller plus loin pour que le plantage soit plus intelligent :

gilles@ubuntu:~$ iotop
Le programme « iotop » n’est pas encore installé. Vous pouvez l’installer en tapant :
sudo apt-get install iotop

Est-ce que la prise en compte du critère {id_mot?} ne pourrait pas être conditionnée à l’existence du plugin Mots, étant donné qu’on sait qu’il existe dans les plugins officiels ? Le code généré serait alors celui sans ce critère, et basta, plus besoin d’avoir à revoir les squelettes de l’espace privé.

Quelque chose me dit que James a envie de faire le Silex de Symphony :wink:

.Gilles

4

Hello,

non on ne va pas réintégrer les mots dans le core, ça n'est en aucun cas une fonctionnalité essentielle et indispensable, au contraire des iterateurs et du job queue qui sont des briques de base.

Il faut/suffit de traiter le cas particulier du critère id_mot, peut-être en déclarant une dépendance de critères dans le compilateur ?
Genre si un critère X n'est pas trouvé mais qu'une dépendance à un plugin Y est déclarée et que ce plugin Y n'est pas activé, alors tout est normal, ne pas produire d'erreur.
Cela permettrait sans doute de traiter les 3 cas de critères soulevés par James.

Pour la dépendance au plugin de filtre image, c'est nouveau dans la 3.1 à cause des filtres de calcul de couleur du thème, car jusqu'ici le core était totalement indépendant de ce point de vue et ne nécessitait aucun filtre image avancé. Ça doit pouvoir se résoudre, peut-être en déplaçant ces 2 filtres, ou en déclarant une version par defaut dans le core ?

5

Re,

6

à noter aussi que le minimum pour un site public dans le cas d’un SPIP nu, est un fichier sommaire.html dans squelettes/ et un squelettes de formulaire d’administration.

7

Immensément moins courant que les sites où il n'y a pas de mots. La base de SPIP tel que les gens le connaissent, c'est d'écrire des articles (comme la plupart des CMS en fait : blog ou magazine complexe compris). Le fait de classer avec des mots, ça par contre c'est complètement en plus (moi ça fait des années que je ne classe plus qu'avec des rubriques, soit principales soit secondaires avec polyhier).

Mais en vérité les rubriques aussi pourraient/devraient être déplacé dans un plugin à part (quand on fait juste un blog simple, on a pas forcément besoin de mettre les articles dans des rubriques).

8

Oui je pense qu'on doit pouvoir trouver une manière de faire "mourir" silencieusement un critère qui n'est pas défini parce qu'un plugin manque.

Mais, plus compliqué évidemment, je me demande si on ne pourrait pas trouver un moyen, un jour, pour ajouter dynamiquement des critères dans telle boucle de tel squelette.

Car là ce cas de {id_mot?} nécessaire dans l'admin, c'est pas spécifique en fait. N'importe quel autre plugin peut avoir besoin de rajouter des critères dans un squelette de liste d'objets par exemple (polyhiérarchie par ex, qui est une autre manière de filtrer). Ça ne peut pas être une surcharge unique, puisque sinon un seul plugin peut le faire.

Bon je n'ai pas de solution évidemment, mais ça fait longtemps que je me dis que c'est un cas qui devrait être générique si on considère que les "listes de choses" doivent pouvoir être filtrées par de nouvelles choses non prévues au départ.

L'exemple le plus simple qui me vient, puisque l'objet central, c'est la page "exec=articles" (qui liste tout) qui devrait pouvoir être personnalisable/améliorable par des plugins, pour rajouter des filtres plus complexes que juste la recherche libre (mots de différents groupes, branche de polyhier, auteurs, etc). Et ça vaut pour n'importe quel objet évidemment (mais surtout ceux qui vont être en nombre important).

9

Ben pourquoi pas, c'est un peu péremptoire comme réponse surtout qu'on a
fait ça pour d'autres ?
Il y a des sites ou les articles ne sont pas utilisés, on les sort ?

Immensément moins courant que les sites où il n'y a pas de mots. La base
de SPIP tel que les gens le connaissent, c'est d'écrire des articles (comme
la plupart des CMS en fait : blog ou magazine complexe compris). Le fait de
classer avec des mots, ça par contre c'est complètement en plus (moi ça
fait des années que je ne classe plus qu'avec des rubriques, soit
principales soit secondaires avec polyhier).

ou de passer des commandes, de poster un "seen", de faire son panier de
légumes, ...

Mais en vérité les rubriques aussi pourraient/devraient être déplacé dans
un plugin à part (quand on fait juste un blog simple, on a pas forcément
besoin de mettre les articles dans des rubriques).

+1

10

Il faut/suffit de traiter le cas particulier du critère id_mot,
peut-être en déclarant une dépendance de critères dans le compilateur ?
Genre si un critère X n'est pas trouvé mais qu'une dépendance à un
plugin Y est déclarée et que ce plugin Y n'est pas activé, alors tout
est normal, ne pas produire d'erreur.
Cela permettrait sans doute de traiter les 3 cas de critères soulevés
par James.

Oui je pense qu'on doit pouvoir trouver une manière de faire "mourir"
silencieusement un critère qui n'est pas défini parce qu'un plugin manque.

Mais, plus compliqué évidemment, je me demande si on ne pourrait pas
trouver un moyen, un jour, pour ajouter dynamiquement des critères dans
telle boucle de tel squelette.

+2 !

Car là ce cas de {id_mot?} nécessaire dans l'admin, c'est pas spécifique
en fait. N'importe quel autre plugin peut avoir besoin de rajouter des
critères dans un squelette de liste d'objets par exemple (polyhiérarchie
par ex, qui est une autre manière de filtrer). Ça ne peut pas être une
surcharge unique, puisque sinon un seul plugin peut le faire.

une sorte de pipeline de critères, quoi ... :slight_smile: En gros, on parle ici du
design pattern "Injection de dépendance", grosso modo.

11

Yop,

12

Yop,

Oui je pense qu'on doit pouvoir trouver une manière de faire "mourir"
silencieusement un critère qui n'est pas défini parce qu'un plugin manque.

Mais, plus compliqué évidemment, je me demande si on ne pourrait pas
trouver un moyen, un jour, pour ajouter dynamiquement des critères dans
telle boucle de tel squelette.

+2 !

Exactement.
Je ne comprends pas pourquoi dans le cas de id_mot on présuppose un
critère qui n'est peut-être pas utilisé. Si on appliquait ce principe plus
souvent je vois pas comment on ferait le code de départ :p.
Donc c'est juste historique et quant à améliorer le système autant
réfléchir à une solution qui tienne la route plutôt qu'à un patch.

Aujourd'hui, on a plusieurs mécanismes pour insérer des fonctionnalités
supplémentaires induites par un plugin:
- les pipelines
- la surcharge
- l'échafaudage

En premier lieu, je trouverais plus logique que le plugin mots surcharge
les boucles avec son critère et que les boucles de SPIP nu soient sans
id_mot.
Après même si on découpe le code pour limiter la duplication ça risque
d'être un peu lourd à l'écriture et à la maintenance (quoique je suis pas
sur qu'on le modifie souvent).

Maintenant, le mieux serait surement d'injecter le critère id_mot via une
sorte de pipeline dans la boucle initiale de SPIP nu (un critère {pipeline}
?).
Je sais pas si c'est possible mais ça me parait séduisant.

Ce n'est ce que "propose" b_b sur son blog ?

:slight_smile:

13

Hello,

non on ne va pas réintégrer les mots dans le core, ça n'est en aucun cas
une fonctionnalité essentielle et indispensable, au contraire des
iterateurs et du job queue qui sont des briques de base.

Pour un SPIP mini, un peu habillé, qui servirait de base à des
distributions totalement indépendante, dont un SPIP classique, oui, je
crois.

Pour un SPIP nu, sur lequel s'appuierait le SPIP un peu habillé (mini), je
me demande quelle fonctionnalité peut encore être retirée ... et j'ai pas
d'apriori.

Il faut/suffit de traiter le cas particulier du critère id_mot, peut-être
en déclarant une dépendance de critères dans le compilateur ?
Genre si un critère X n'est pas trouvé mais qu'une dépendance à un plugin
Y est déclarée et que ce plugin Y n'est pas activé, alors tout est normal,
ne pas produire d'erreur.
Cela permettrait sans doute de traiter les 3 cas de critères soulevés par
James.

Le pipeline pre_boucle, je l'avais complètement oublié. Je vais regarder ça.

Pour la dépendance au plugin de filtre image, c'est nouveau dans la 3.1 à
cause des filtres de calcul de couleur du thème, car jusqu'ici le core
était totalement indépendant de ce point de vue et ne nécessitait aucun
filtre image avancé. Ça doit pouvoir se résoudre, peut-être en déplaçant
ces 2 filtres, ou en déclarant une version par defaut dans le core ?

dans ecrire/inc/filtres_images_mini.php ? une fonction
filtre_couleur_saturation_dist($couleur, $val) { return $coueur; }
suffirait sans doute, j'imagine ?

14

Pour un SPIP nu, sur lequel s'appuierait le SPIP un peu habillé (mini), je
me demande quelle fonctionnalité peut encore être retirée ... et j'ai pas
d'apriori.

Le choix de job_queue de stocker les jobs dans une table n'est qu'une
possibilité parmi d'autres. En ce sens, il n'est pas indispensable. Mais
par contre si on devait retirer job_queue, il faudrait laisser une API
minimaliste de manière à ce que tout le puisse envoyer des travaux (à
exécuter tout de suite, le cas échéant) sans devoir se poser la question de
la présence ou non du plugin.

Pour les itérateurs, ils sont complètement fondus dans le compilo
désormais, c'est la généralisation des boucles, et ça n'a plus grand sens
d'en parler à part. Est-ce qu'on peut imaginer avoir un SPIP sans compilo,
ça peut-être même si je ne vois pas bien ce que ça donnerait.

Ce qui serait sympa ce serait d'arriver à n'avoir aucune dépendance à MySQL
… et au final il ne va rester que spip_meta, qui pourrait peut-être être
géré "à plat".

-- Fil

15

Puisque plus ou moins la question se pose de ce qu'est le core de spip,
je rappelle la question du privé, toute l'UI de /ecrire,
qui pourrait être mise en plugin.

Mais pour le SPIP dist de base, outre les brèves,
ce sont surtout les pétitions qui semblent très périphériques
et qui devraient, à mon avis, sortir de la dist.

JL

16

Un SPIP sans compilo, je ne vois pas bien, mais le compilo sans SPIP, ça je vois bien.

17

Fait.

Pour l'histoire des critères, j'ai plus de mal ...

18

Yo,

19

Perso c'est en priorité l'inverse que je verrai : le compilo tout seul sans le reste, en tant que logiciel à part (trouver un nom…).

Sans les choses propres à SPIP (articles, etc) donc. Ces dernières seraient une extension du langage de template propre à SPIP (propre aux tables, objets, etc, de SPIP).

20

Je viens de faire l’essai. J’ai codé un critère {pipeline} qui appelle un pipeline inserer_critere, remplacé {id_mot?} dans la boucle “_liste_art” par ce critère et ajouté une fonction dans le plugin mots qui insère le critère {id_mot?} via le pipeline. Et ça marche.

Le truc, tel que je l’ai codé, c’est que ce critère {id_mot?} sera inséré dans absolument toutes les boucles qui exploiteront {pipeline}. On pourrait limiter aux seules boucles ARTICLES, ou ARTICLES+RUBRIQUES, par exemple. mais ça sera appliqué quand même à toutes les boucles ARTICLES (ou ARTICLES+RUBRIQUES) et on ne le souhaite pas forcément…

De même, si un autre plugin utilise le pipeline inserer_critere, pour ajouter son critère, on se retrouve avec 2 critères ajoutés systématiquement à toutes les boucles… et on ne le souhaite pas forcément, non plus …

Et je ne suis pas certain que d’ajouter un paramètre soit judicieux : {pipeline truc} qui n’appliquerait que les critères qui s’enregistrent dans “truc”, je n’y crois pas beaucoup.

Bref, je crois que soit il manque quelque chose à ce concept, soit que ce n’est pas le bon.

Mais je fournis le patch si vous voulez.