Bon, moi qui ai toujours trolle pour defendre l'idee que SPIP 2.0 ne
sortirait pas sous ce nom la !!!
mais bon peu importe le nom la perspective d une version stable me rejouie 
alors si je reprends un peu les differents mails cela donne quelque
chose de ce genre :
FORMULAIRES :
Arno :
on met en place une «ferme» plugins, bien foutue, façon plugins
Mozilla, accessible et compréhensible par le webmestre qui n'a pas un
niveau bac+4 en manipulation SVN;
Fil :
Les plugins sont actuellement encore un peu difficiles d'accès :
c'est sans doute pas grand chose à faire : un peu d'interface pour la
partie chargeur, un peu d'interface/doc pour la partie
spip.net/plugins/ -- plus ils seront faciles à gérer, moins le débat
"officiel/pas officiel" qui nous pourrit la vie aura de l'importance.
On pourra alors avoir une base de code minimale (dite "core"), une (ou
plusieurs) "distributions" (officielles ou non), et une foule de
bidules (modules, plugins, squelettes) à ajouter pour activer telle ou
telle fonctionnalité.
Bonjour,
juste ceci:
le débat officiel / pas officiel, pour un webmestre qui n'a pas bac+4 en plugins, c'est qu'il n'est ni trivial ni simple en débarquant dans l'univers de spip de déterminer la "solidité" d'un plugin, notamment sur les questions
- de sa compatibilité (version de spip, autres plugs)
- et de son niveau d'espérance de pérennisation (suivra-t-il les évolutions de spip).
De ce point de vue là, la question "officielle" n'est pas dénuée d'intérêt.
Bon travail
RB
Ben. . a écrit :
CFG
----------------------------------------------------------------Arno* :
le plugin CFG ne doit pas être un plugin désactivable. C'est
totalement incohérent: un plugin qui désactive les autres plugins,
c'est incohérent.
On pourrait aussi dire que c'est au plugins de ne pas avoir besoin de "nécessiter" CFG, mais de simplement profiter de sa présence s'il est actif... mais je suis d'accord avec ce point, CFG est devenu une référence et il faut en tenir compte.
Soit on le met dans le core, soit on en fait un /
lib. Et on le rend multilingue, parce que bon, c'est pas possible, là.
(Et faudra lui faire un lifting un jour, parce que son interface est
pas aux normes SPIP :-)).
Je coupe aux calomnies 
:
-* en quoi CFG n'est pas multilingue ?
-* en quoi il n'a pas une interface aux 'normes' SPIP ?
Fil : cfg est super, mais contient tellement de trucs "ultra puissants
mais super complexes" que c'est un morceau de code difficile à faire
avaler au core ; si on veut le mettre dans le core (et en effet il
faudrait, conceptuellement ça n'a pas de sens qu'il n'y soit pas), il
faut le simplifier, voire en réécrire une version minimaliste.Ben: et qu'en pense Matthieu qui a bien plonge les mains dedans ?
Bon, puisque l'on me demande mon avis :
- CFG est super, je trouve aussi, au moins pour réaliser des formulaires simples qui stockent des informations dans spip_meta. C'est rapide et efficace.
- CFG peut aussi stocker dans n'importe quel champ de n'importe quelle table connue de SPIP, (en sérialisant ou non) et c'est un point aussi très intéressant. Toggg proposait par exemple de remplir la colonne 'extra' pour stocker des informations complémentaires à la table auteur... Comme extra sert à autre chose, c'est certainement l'occasion d'ajouter un champs 'prefs' ou 'cfg' sur certaines tables.
- CFG peut tout aussi attaquer une table en écriture (un input = un champ de la table) à la condition que cette table ait une Primary Key autoincrement. A la vue de tout cela, oui, CFG mérite d'entrer dans le core, mais pas, je pense dans son état actuel
Car il y a maintenant aussi l'API des formulaires de cerdic qui est assez simple et gère mieux l'ajax que les essais que j'ai pu faire avec les formulaires CFG dans la partie publique. Idéalement, pouvoir faire #FORMULAIRE_CFG{nom_du_cfg} en utilisant cette API serait génial mais je n'ai pas réussi à faire cohabiter les deux.
Comme Esj suggérait de faire aussi maigrir les redondances dans SPIP... et je me dis que les 'formulaires' et 'cfg' sont très semblables et mériteraient de converger en partie.
Ben :
Ah tiens je n avais pas vu qu il y avait une ebauche ici :
http://spip.net/plugins
Oui Ben, couramment, on appelle cela le dossier "plugins" ^^
Arno :
– on définit clairement l'API des plugins, et on la documente
progressivement– on définit l'API des #EXTRA (vach'tement pratique pour les petites
bidouilles), et on les documente (pour l'instant, il n'y a qu'un
article sur contrib, qui dit qu'il faut patcher SPIP!)
J'avais cru ouir que les #EXTRA étaient voués à une disparition dans un avenir incertain... j'avoue ne jamais les avoir testés, vu la documentation débordante sur le sujet ^^
– on définit l'API des accès SQL,
Ca c'est fait déjà sur spip.net (non publié)
MM.
Bonsoir,
Bien qu'assez éloigné du web (et donc de SPIP) pour le moment, je ne
peux éviter de tilter sur l'occurrence d'un "SPIP 2.0"; et en profiter
pour lire les derniers échanges sur la liste.
Dans la compréhension que je m'en étais fait, l'horizon "SPIP 2.0"
tenait principalement à l'idée de rendre générique la définition des
objets manipulés par SPIP, tout en gardant un cadre de référence
(situation unique dans une arborescence de rubriques, notamment, commun
à tous les objets). Ce qui impliquait d'une part la possibilité de créer
de nouveaux objets (et de choisir de les lier, ou non, aux mots-clés,
auteurs,... de les doter ou non d'un logo, etc) et de les gérer de
manière transparente dans l'interface privée. Et d'autre part la
possibilité de modifier les objets existants autrement par des champs
extra dont les limites (indexation et surtout tri) sont importantes.
Par exemple, j'imaginais que "SPIP 2.0" allait permettre la gestion
d'une bibliothèque (ce que je fais depuis plusieurs années, mais avec
force bidouilles et champs extra), en définissant un objet "livre" doté
des champs qui vont bien, et ainsi de suite.
Si je comprends bien, cet objectif (si c'était bien ça qui était
l'horizon de la communauté) n'est plus présent, ou en tout cas pas comme
définition de l'étape 2.0. Exact ?
Mes deux sous (et un coup de chapeau au passage aux artistes et à leur
endurance)
François
PS : Concernant les plugins, le point vraiment central me semble être
leur "certification" (que ce qui est indiqué comme stable le soit
vraiment, avec indication des versions compatibles, etc) et un minimum
de doc. Si on ne suit pas la zone, c'est vraiment pas évident de savoir
où se trouvent les choses intéressantes, ce qui est fiable et ce qui
n'est pas, etc.
Comme tu le soulignes, un tant soit peu de documentation serait le bienvenu, et si possible, un peu standardisé.
Les grands plugins comme CFG sont relativement bien documentés, mais tous ne le sont pas/le sont sur le site de l'auteur/ne sont pas à jour.
-----Message d'origine-----