On 15/04/2010 09:57, Simon Camerlo wrote:
Et d'ailleurs, le CS
pourrait devenir un "méta-plugin" qui ne ferait qu'altérer l'interface
de gestion des plugins sans modifier ce qui se passe dessous, non ? Je
ne comprends pas bien la nécessité de construire un niveau intermédiaire
entre spip et les plugins, particulièrement maintenant que l'interface
est vraiment agréable à utiliser et de plus en plus facilement
modifiable par les plugins eux-même (chose que j'ai du mal à comprendre
avec CFG aussi d'un point de vue ergonomique).
J'avais discuté un peu avec Pat il n'y a pas très longtemps, et il m'a semblé qu'il était également d'accord avec ce constat (il me reprendra le cas échéant). Une sorte de méta plugin facilitant la gestion des configurations via une API, ou modifiant la structure des pages de configuration, ou je ne sais quoi, mais qui permette d'avoir chaque lame de manière totalement autonome.
On en revient à des problèmes récurrents qui ont vu naître certains plugins et solutions plus ou moins fiables et fonctionnelles. Je mettrais un peu dans le même panier CFG, Kconf, CS et STEP.
Ils regroupent à eux tous divers outils pour :
- faciliter l'installation de fonctionnalités et leurs dépendances éventuelles, avec des options de tris par catégories (CS et STEP)
- faciliter la configuration d'éléments pour les utilisateurs (CFG, Kconf, CS)
- offrent une API pour simplifier la création de formulaire de configuration (CFG, Kconf, CS)
- offre une API pour se brancher sur des pipelines (CS)
***
A mon sens, il ne faut qu'un seul plugin, ou plutot, faisant partie intégrante de SPIP pour gérer l'installation, la recherche de fonctionnalités, les tris par catégorie, en tenant compte si possible des dépendances (à mon sens c'est important pour pas agacer les utilisateurs : tu cliques «spip-zen», ça t'installe l'ensemble des libs et plugins nécessaires).
Pour les configurateurs, c'est vraiment plus délicat. Je ne m'étends pas sur Kconf que je ne connais pas vraiment. CFG, et CS offrent 2 moyens différents de créer des interfaces de configuration. Dans les deux cas, il manque un peu ce que repproche ARNO* à juste titre, c'est à dire une interface «intégrée». Chaque configuration devrait se placer à l'endroit idéal dans SPIP (oui, c'est quasi impossible), mais pas dans ?exec=cfg ou dans ?exec=CS : un plugin x doit avoir sa configuration sur un lieu y quelque soit le configurateur qu'il utilise.
Donc, je dirais bien que ce sont des plugins qui, lorsqu'une interface dans SPIP de recherche, installation de plugin par catégorie sera là, auront fait leurs temps. Il reste à inventer la suite. Où placer les configurations ? avec quelle API ?
Bien que je le maintienne, je suis pas un grand fan de CFG, il y a certainement mieux à inventer au niveau interface. Cependant il a un grand avantage actuellement, c'est que ses formulaires sont en CVT et peuvent être appelés n'importe où, en ajax ou non. Par conséquent, il serait enviseageable de dire «tel formulaire se place ici» (et non sur ?exec=cfg).
***
Juste pour info, dans le CFG2, plugin d'expérimentations, on peut écrire n'importe où : #FORMULAIRE_CONFIGURER{toto} et avoir un fichier : configurer/form_toto.html de la sorte, contenant simplement les paramètres CFG et les saisies qu'on veut. Simple, rapide et suffisant pour la plupart des configurations.
<!-- nom=sarka -->
<!-- casier=style/couleurs -->
<!-- autoriser=administrateur -->
<!-- refus=<:cfg:refus_administrateur:> -->
[(#SAISIE{couleur, fonda, label=<:sarka:label_style_fond:>})]
[(#SAISIE{couleur, face, label=<:sarka:label_style_face:>})]
[(#SAISIE{couleur, titre, label=<:sarka:label_style_titre:>})]
[(#SAISIE{couleur, bordure, label=<:sarka:label_style_bordure:>})]
[(#SAISIE{input, texte, label=Du texte})]
[(#SAISIE{textarea, larea, label=Du texte plus gros})]
--
MM.
