Action 11 - Extension de plugins

Bonsoir,
Oui c'est un point très utile à connaitre avant l'installation d'un plugin.
En fait il y a (au moins) trois cas possibles :
1- les plugins qui dépendent (le <utilise simple),
2- les plugins qui s'imbriquent (les divers Lister de teddy )...
3- les plugins qui se composent (comme l'ensemble de gestion de Commerce)
+4 les plugins qui couvrent plusieurs catégories (archétype = le CS !) .. ce peut apporter

Un second point concerne le nombre d'auteurs concernés...
- on a surtout des exemples à un meme auteur jusqu'à présent,
- mais on aura plus souvent à gérer des projets plus collectifs (cf. les espoirs de projets de Rasta..... et je soutiens cette perspective)

Le cas n° 1 peut etre traité par :
- un lien A2A vers l'article de base du plugin (à défaut de lien vers la rubrique)
- un chaînage spécifique (affiché également en spécifique) vers les rubriques "plugin" concernées : pourrait être alors automatisé par lecture de paquet.xml (?)
- (pour mémoire) un chainage par mots-clés (lourd dans ce cas...)

Les cas 2 et 3 me paraîtraient assez naturellement des sous-rubrique d'une meme rubrique de niveau 3 (quoique pour le cas "commerce" je pense que cela est déja d'un niveau 1 ou 2) ; cela voudrait dire aussi que certaines "rubriques-plugins" pourront devoir être descendues d'un niveau sous un nouveau regroupement : est-ce un problème (techniquement, surement pas) ? Editorialement, ou du point de vue de la recherche & navigation.... je ne pense pas non plus, mais dites-moi si je me trompe ?

Encore une fois, la solution naturelle en SPIP est de passer par des mots-clés, plutôt que des champs extras dédiés (donc mono-valués, avec les limitations que cela induit à terme), mais j'ai bien ressenti que vous y sembliez totalement opposés (je ne comprends toujours pas pourquoi...) ; bien sûr il faut en avoir une définition explicite (qui -clairement- manquait totalement jusqu'ici dans Contrib), mais depuis longtemps on sait que la hiérarchie stricte est notoirement insuffisante pour les organisations (et a fortiori pour rendre compte de notions sémantiques...)....

Cela demandera simplement des squelettes et formulaires de recherche atypiques, mais restant totalement standard en SPIP...

Et si on évitait de faire une usine à gaz qui deviendra ingérable après quelques mois d'utilisation ?

Le cas 1 dont tu parles est natif une fois qu'on a la base SVP complète comme cela est prévu. Donc c'est disponible sans rien faire et si on intègre la page plugin.html de Plugins SPIP ce sera visible sans rien faire d'autre.

Les cas 2 et 3, j'avoue que je ne comprends pas la différence. Mais soit je considère que c'est la même chose.
Ceci étant, pourquoi ne pas avoir un article au niveau 1, qui, au lieu de lister les plugins sans expliquer en quoi ils participent à un ensemble, décrit véritablement l'écosystème complet et la fonction de chaque plugin dans cet écosystème. C'est simple, ça peut évoluer facilement, c'est humainement lisible et ça ne casse en rien la structure proposée.
Et non je suis opposé à créer des sous-rubriques qui ne seraient plus liées à un préfixe ou une catégorie car c'est cette structure qui protègera Contrib du retour à l'anarchie.

Perso je voyais plutot une informatique dans paquet.xml qui puisse être ensuite ettre converti en champ extra (ou pas) pour mettre un lien dans en marge de l'article dans contrib, à côté de numéro de version, etc. Idéalement cela devrait pouvoir aller dans les deux sens ("ce plugin étend ce plugin" ou "ce plugin est étendu par ces plugins")

On a plusieurs fois parlé d'une balise "suggéré" dans les XML (mais ya pas de notion de sens), pour dire les plugins qui vont bien avec, sans forcément les utiliser non plus. Après si c'est dans la description interne du plugin, faut voir à long terme ce qu'il y a dans le JSON pour Composer aussi.

La suggestion c'est encore autre chose. Je sais pas par ex si formidable
doit suggérer toutes ses extensions ;)

J'ai un peu peur que cette notion plutôt subtile ne soit confondue avec la balise utilise du paquet.xml. Je crois franchement plus à un article descriptif qui lui fera les liens. Ou peut-être un article spécial ?

mouais, je me dis que quitte à formaliser / automatiser, autant le faire jusqu'au bout non ?

mais oui la subtilité entre étend et utilise est pas évident.

Ya des tas de relations possibles. L'extension de plugin en est une, la dépendance et le nécessite aussi. On a parlé ailleurs de "familles de plugins". Je trouve que tout ça peut rentrer de manière assez lâche dans des "sélections" (ou des "grappes" si on veut y entrer des rubriques) polyvalentes et pas trop encadrées, et dont seul l'usage (edition du titre et description d'une sélection) précisera l'usage : famille de plugin ou extensions d'un plugin etc
Aprés c'est peut être pas évident de rester simple avec de tels outils.

donc tu couperait tout lien avec des infos dans paquet.xml?
perso, pour ce besoin, je préfère les grappes aux selections (ensemble
d'objet plutot que selection d'info edito)

Je n'avais pas pensé à cet aspect là, mais ça ne semble pas souhaitable de couper le lien avec paquet.xml car ça amène à disperser des informations. Par contre, si ces infos sont stockées dans le paquet.xml (et certaines le sont déjà), la fusion de plugins.spip.net et de contrib amene à envisager transformer certaines parties des formulaires de contrib en interfaces d'édition de certaines parties des paquet.xml... (de manière encadrée par l'UI et non plus en traitement de texte)