Framavox

Action 11 - Extension de plugins

Maïeul
Maïeul Public Seen by 35

Certains plugins sont des extensions d'autre plugins. Par ex. Rainer propose un certain nombre de plugins avec un noyau et plein d'autres. Formidable dispose également de plugin satelitte (formulaires de participation, réponses commentées, etc.)

il serait bon de pouvoir le signaler d'une manière ou d'une autre.

Y

YannX May 3rd, 2019 18:22

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...

Lupinacci Eric

Lupinacci Eric May 4th, 2019 07:07

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.

Maïeul

Maïeul May 4th, 2019 12:14

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

RastaPopoulos

RastaPopoulos May 4th, 2019 12:28

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.

Maïeul

Maïeul May 4th, 2019 12:32

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

Lupinacci Eric

Lupinacci Eric May 4th, 2019 13:06

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 ?

Maïeul

Maïeul May 4th, 2019 13:07

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.

Y

YannX May 4th, 2019 13:14

Je suis bien d'accord pour cette démarche d'un article général (cela fait longtemps qu'on caresse cette idée ave JLuc) : toutefois je perçois deux points à préciser :
- qui le gère et l'édite (ce n'est pas forcément de la responsabilité d'un admin.restreint d'un plugin / plusieurs pourraient vouloir y participer / et comment gérer l'harmonisation éditoriale)
- dans ce type de cas, on crée donc une sous-rubrique chapeautant les plugins sous le niveau 2 de catégories (en effet, imaginons que des spipeurs créent une deuxieme forme d'implémentation incompatible pour le meme groupe de foncitonnalités : en l'écrivant je m'aperçois que cela rejoint votre discussion sur les familles de squelettes.

Mais faire apparaitre les plugins "nécessités" (voire "utilisés") dans la page de plugin (dans un encart..) me paraitrait fort utile...
Par contre, je ne suis pas convaincu par des "suggestions d'extensions" automatisées...

JLuc

JLuc May 14th, 2019 19:16

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.

Maïeul

Maïeul May 15th, 2019 07:55

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)

JLuc

JLuc May 15th, 2019 09:02

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)

RastaPopoulos

RastaPopoulos May 16th, 2019 13:01

Moi je préfère les sélections parce que c'est moi qui l'ai fait. :p

Non mais surtout qu'on peut aussi y mettre n'importe quel objet comme les grappes, sauf qu'on peut personnaliser titre et texte. Et quand il s'agit de sélection manuelle, c'est justement là que tu peux avoir besoin de texte libre pour donner un sens. Dire "Vous pouvez aussi aller voir ce plugin qui permet ceci cela en plus", et ça pour chaque élément de la sélection. Donc Sélections éditoriales me parait mieux que Grappes pour ça (et en plus c'est mieux maintenu non ?) :)

Maïeul

Maïeul May 16th, 2019 13:11

c'est je crois ce concept de titre personnalisable et texte modifiable,
et pas synchronisé avec les objets liés, qui me parait bizarre pour les
selection editorial.

Cela étant, je me demande si on devrait pas plutot avoir des liens A2A
ou O2O typé. Ca permettrait plus de cohérence, au sein de contrib, me
semble-t-il.

Mais reste la question de savoir si on indique cela aussi dans le xml du
plugin.

Maïeul

Maïeul May 18th, 2019 14:30

suite à la proposition d'Eric (sur la listes) de laissons tomber la catégorisation dans paquet.xml mais de garder cela uniquement dans le référentiel de plugin (ce que je soutiens), je pense qu'il faudrait avoir la même logique pour tous les plugin connexes.

Je verrais bien du coup, sur le referentiel de contrib, différents options pour relier un plugin à un autre dans une relation qui ne soit pas de dépendance / d'utilisation. Je vois, pour l'instant:
- extension de (et du coup, à l'inverse : est étendu par)
- remplace
- s'inscrit dans un chaine pour répondre à des besoins (je suis pas hyper convaincu de l'intutilié, mais en gros c'est pour relier par ex tout les plugins de l'API de nwesletter).

Je pense qu'il vaut mieux éviter les selections editoriales ou les grappes, il vaut mieux un truc fixe défini dans le workflow de documentation / referentil de plugin,

cy_altern

cy_altern May 19th, 2019 15:48

Le extension de me semble un concept incontournable éditorialement, que cet attribut soit ou non inclut dans le paquet.xml.
Cf pour exemple actuel les 4 sous-rubriques de Formidable (https://contrib.spip.net/Formidable), "Abonnements à des listes de diffusion", "Formulaire de participation avec Formidable", "Réponses commentées" et "Fusion de formulaires avec Formidable".
Point de vue rubricage j'imagine qu'on ne déroge pas à la règle générale: il s'agit de rubriques-plugins, à priori rangées dans la même catégorie que le plugin "maître" (Formidable dans cet exemple), mais il semble indispensable de pouvoir signifier que ce sont des plugins qui étendent les possibilités d'un autre auxquels ils sont totalement inféodé (concept très différent du "necessite")
Après, je dirais que ça n'est pas une grosse contrainte pour les concepteurs de plugins de gérer ce extension de dans leur paquet.xml. A l'inverse le déporter en tant qu'attribut (CE?) de la rubrique-plugin sur Contrib permet que tous les auteurs ayant les droits sur cette rubrique puissent l'ajouter si le codeur l'a oublié...

JLuc

JLuc May 20th, 2019 12:08

Euh... qu'est ce donc qu'apporte ce concept d' « extension » par rapport aux « necessite » déjà présents aux côté des « utilise » ?

Maïeul

Maïeul May 20th, 2019 12:45

necessite indique qu'un plugiin a besoin d'un auttre pour fonctionner. C'est une dépendance technique, Utilise indique qu'un plugin connaît l'existence d'un autre et peut en tirer profit, c'est une amélioration pour le plugin qui a le utilise. extension indique qu'un plugin apporte des fonctionnalités supplémentaire à un plugin. C'est une amélioration fonctionnelle.

Maïeul

Maïeul May 20th, 2019 12:46

formidable necessite saisie, mais n'étend pas saisie. C'est juste l'outil technique qui lui sert de base. Par contre "fusion de formulaire" ajoute une fonctionnalité à formidable : c'est une extension

JLuc

JLuc May 21st, 2019 06:38

Ok les exemples étaient nécessaires car sinon ça me parlait pas. Je vois mieux maintenant... mais l'absence de la visibilité de cette notion d'extension ne m'a jamais manqué dans mon usage de SPIP. Dans quelles circonstances penses tu que c'est utile ?

JLuc

JLuc May 21st, 2019 06:43

Hier par contre, j'ai été confronté à une difficulté induite par l'absence de visibilité des "familles de plugins". J'ai voulu installer zen-garden et avec mes souvenirs plus ou moins confirmés par la doc, j'ai vu qu'il fonctionnait avec zpip (j'étais un peu embêté car zpip est obsolète, mais j'ai eu l'impression qu'il ne fonctionnait pas avec z-core). Par contre impossible de savoir quels thèmes vont bien avec zpip. J'ai du en charger à l'aveuglette. Ça, ça me semble gênant car ça impacte un public débutant, peu outillé et particulièrement sensible.
Je met ça en rapport aec la notion d'extension car ici il faudrait la notion de "famille de plugins". Je ne sais pas s'il faut définir plein de notions spécifiques comme "extension" ou "famille de thèmes" etc, ou permettre des "grappes" ou "sélections" polyvalentes, avec un titre et un descriptif pour chacune de ces familles... "Plugins Z compatibles pour zpip et zen-garden", "extensions de formidable"...

JLuc

JLuc May 21st, 2019 06:48

Et lol à la réflexion je vois que même avec les exemples, la distinction entre "extension" et "necessite" ne me parle pas ! (d'où : dans quelles circonstances penses tu que c'est utile ?)

Maïeul

Maïeul May 21st, 2019 08:44

typiquement pour la famille formidable, c'est utile. Mais ca relève du
documentaire, pas du technique.

Lupinacci Eric

Lupinacci Eric May 22nd, 2019 07:17

Ce terme d'extension me parait un peu confus même si il décrit bien le cas de formidable et de son orchestre, car c'est l'ancien terme des plugins. En fait, on a des "types de connexité" entre plugins :
- le necessite des paquet.xml qui est claire et net
- l'utilise des paquet.xml qui est bien moins clair car pas systématique puisque son but est d'abord de gérer le chemin.
- et les catégories.

A cela on peut ajouter d'autres types de connexité, comme un "lire aussi" mais je suis d'accord avec Maieul que ces autres types doivent rester éditoriaux. Et aussi je les limiterais : a-t-on besoin de plus qu'un lire aussi ? A réfléchir.

JLuc

JLuc May 23rd, 2019 07:15

Je comprend la réticence à ajouter un autre élément structurel.
Mais le fait est qu'il y a une difficulté actuellement pour relier certaines documentation :
- sans l'article "Liste des squelettes HTML5Up" il n'y aurait que la recherche pour trouver les articles HTML5Up (pour autant qu'on sache ou imagine qu'il y en a plusieurs). Cet article existe car je l'ai créé, mais dans d'autres thématiques, il n'existe pas.
- comment savoir quels thèmes vont avec zen-garden ? Je sais pas et ça me semble critique pour ce plugin tant qu'il n'y a pas d'article les répertoriant - et il peut ne jamais y en avoir. Ou avec bank ?

JLuc

JLuc May 23rd, 2019 07:16

Pour le moins le site peut afficher la liste réciproque des "utilise" et "necessite" : la liste des plugins qui utilisent ou nécessitent le plugin courant. Ça répondra à un certain nombre de besoins (voir les membres de la famille de "bank" par exemple)... mais pas à d'autres (pour HTML5up par exemple, il n'y a pas de dépendance structurelle).

Lupinacci Eric

Lupinacci Eric May 28th, 2019 05:57

A mon avis, il faut laisser les utilise et les necessite dans les paquet sans rien rajouter pour l'instant. Les autres regroupements dont tu parles sont possibles via du rédactionnel ou du rubricage (yc mot-clé). Mais franchement le jour où il nous restera plus que ça, je serais content !
Maintenant, une famille de squelettes c'est différent d'un écosystème de plugins comme bank et tout ce qui a attrait au commerce.