Des DTD pour décrire et archiver les plugins - commentaires

Des DTD pour décrire et archiver les plugins

Nouvelle réflexion sur la question des chaînes de langue, lié au développement de l'outil de migration de plugin.xml vers paquet.xml. A partir du moment où le nom des chaînes des langues pour les informations slogan et description sont contraints, il n'y a même plus besoin d'écrire ces deux balises dans le fichier puisque leur localisation est toujours la même. D'ailleurs ce fichier est nécessaire à la mise en œuvre du plugin, mais ces chaînes n'ont qu'un rôle informatif.

On convient donc finalement que ces deux informations figurent dans un fichier du répertoire « lang » du plugin, dont le nom est celui du préfixe du plugin suivi de « -description_ » puis du nom de la langue quand une traduction existe. Ainsi, un plugin est disponible dans une langue si ce fichier existe, et un utilisateur intéressé, plutôt que de lire le fichier plugin.xml, ira lire directement le fichier en question, dans la langue de son choix. Ces fichiers supplémentaires facilitent la lecture pour l'utilisateur, et ne nécessitent d'être chargés que dans la page d'administration des plugins, et un seul à la fois (correspondant à la langue du visiteur de cette page). Ils seront aussi considérés comme prioritaires par les traducteurs, étant de petite taille mais comportant des informations essentielles.

Des DTD pour décrire et archiver les plugins

Hum, j'avais regardé s'il y avait des balises « fonctions » et « options » comportant des espaces, donc plusieurs fichiers, effectivement ce n'était pas le bon test, ce qu'il faut c'est regarder s'il y a plusieurs occurrences de ces balises dans un même fichier plugin.xml.

Pour « option » il y a 7 plugins où cette balise apparait plusieurs fois, mais examen fait c'est le cas où la balise « plugin » apparaît plusieurs fois, il n'y a donc qu'en fait qu'un seul fichier inclus (sauf « corbeille » mais ça semble clairement une erreur dans ce fichier).

Pour la balise « fonctions » il y a 22 fichiers plugin.xml où elle apparait plusieurs fois , dont 20 avec une seule balise plugin. Sur 801 fichiers, il y en a donc même pas 3% où il faudra recourir à la solution du fichier en incluant des autres. Pas dramatique. Il serait intéressant de regarder pourquoi ces plugins éprouvent le besoin de faire ça. Au moins 9 le font pour charger des balises à la compilation, alors que le compilateur cherche automatiquement un fichier portant le nom d'une balise inconnue : ce serait le moment d'exploiter plus à fond ses possibilité.

Des DTD pour décrire et archiver les plugins

« loc » c'est le début de pleins de mots, par exemple « localisation ». Evidemment on pense à « chemin » mais on ne va donner à un attribut le même nom que sa balise. Je pense qu'on arrivera à rien si on fait des remarques au cas par cas, il faut tout considérer d'un coup, et se donner une ligne de conduite dans le choix des noms.

pour la double occurrence de « compatible », c'est justement ici que l'emboîtement XML est intéressant : on donne une valeur qui s'applique a priori à toutes les versions, et pour celles ayant des compatibilités spécifiques on raffine.

Des DTD pour décrire et archiver les plugins

Le premier de la liste, et quasiment le plus utilisé l'a :

http://zone.spip.org/trac/spip-zone/browser/_plugins_/spip-bonux-2/plugin.xml#L10

Des DTD pour décrire et archiver les plugins

« loc » ne me parle pas... « location » ? un autre terme anglais ?
pour « compatible » ce n'est pas sa présence elle-même, mais sa présence à 2 emplacements possibles différents dans le fichier plugin.xml qui me questionne.

Des DTD pour décrire et archiver les plugins

La page de l'auteur sur Spip-Contrib, c'est une bonne idée pour éviter le Spam de l'email en effet. Toutefois ce n'est pas là qu'on trouvera des infos sur le plugin, mais dans l'URL donnée par l'attribut lien.

Cela dit ça oblige les auteurs à s'ouvrir un compte sur Spip-Contrib, et que le squelette auteur de ce site relaie bien les messages vers l'adresse mail, ce qui n'est pas le cas à l'heure où j'écris.

Des DTD pour décrire et archiver les plugins

Oui, excellente idée que cette DTD et bravo pour tout ce boulot !

Des DTD pour décrire et archiver les plugins

L'attribut « mail » ne devrait surtout pas être obligatoire : mieux vaut imposer de pointer vers une page profil que d'imposer de divulguer l'adresse courriel, qui me semble être une information personnelle qui n'a pas à être rendue publique !

Pointer vers la page SPIP-Contrib de l'auteur me semble tout à fait pertinent et bien plus intéressant : cela permet à l'utilisateur du plugin d'avoir une chance de trouver réponse à ses questions, en ligne, de façon autonome, tout en lui laissant la possibilité de contacter l'auteur le cas échéant.

Des DTD pour décrire et archiver les plugins

Sur les 801 plugins de Spip-Zone, aucun n'indique plusieurs fichiers pour les balises Option et Fonction, possibilité d'ailleurs assez redondante avec le fait de pouvoir indiquer un fichier à charger pour chaque pipeline déclaré (sous-balise Include dans le plugins.xml actuel, attribut path dans la DTD proposée). On ne perd donc rien par rapport à l'usage effectif actuel, et il est de fait beaucoup plus lisible d'associer un seul fichier à une seule intention (ce fichier pour ce pipeline), plutôt que de déclarer plusieurs fichiers sans pouvoir dire pourquoi ils se présentent ainsi.

Des DTD pour décrire et archiver les plugins

Je viens de penser à un truc. Actuellement il est possible de définir plusieurs fichiers et . Ce qui permet de dispatcher les fonctionnalités dans plusieurs endroits pour plus de lisibilité. Par ex pour les fonctions, un fichier pour les filtres, un pour les balises, voire même un par balise s'il y a beaucoup de choses dans chaque définition, etc. C'est plus propre, plus lisible. La DTD propose de supprimer la déclaration et donc de n'avoir plus qu'un seul fichier de chaque type. Quid ? On fait un fichier avec que des include_spip() dedans ? (Pourquoi pas hein, c'est juste pour être sûr.)

Des DTD pour décrire et archiver les plugins

pour « path », ok pour le remplacer mais je propose plutôt « loc » car « src » est utilisé ailleurs pour une URI, ce n'est pas le cas ici il vaut mieux éviter de prendre le même nom pour deux choses de types différents ;

pour « prefix » je serais plutôt d'accord, mais l'habitude est tellement enracinée que je crains les erreurs à répétition ;

URL de l'auteur, ok bonne idée ;

pour « compatible » c'est expliqué dans le texte : certaines versions du plugin peuvent être compatibles avec certaines versions de SPIP mais pas d'autres, ça permet une information très précise.

Des DTD pour décrire et archiver les plugins

Je n'avais pas vu les fichiers joints.

Plusieurs remarques me viennent à l'esprit, à chaud :

éviter de mélanger le français et l'anglais. Les occurrences « path » (src), « prefix » (prefixe) devraient être modifiées
ajouter « url » éventuelle d'un site sur l'auteur ?
je ne comprends pas pourquoi « compatible » est marqué à la fois dans l'attribut de la balise « paquet », ainsi que dans le tag « spip » (cas de l'exemple Fancy) ; il est uniquement dans « paquet » pour l'autre exemple. Je serai pour ne garder qu'une seule des écritures (avec l'encadrement de version spip)

MM.

Des DTD pour décrire et archiver les plugins

L'un des rôles des balises auteur est de fournir un moyen de rentrer en contact avec celui ou ceux qui s'occupent effectivement du Plugin (la page d'accueil n'a pas forcément de forum, et dans le cas d'un communication d'une faille de sécurité, ce n'est de toutes façons pas sur un forum qu'il faut la signaler). Il me semble donc

qu'il faut rendre l'attribut mail obligatoire (si vraiment l'auteur ne veut pas la donner il lui suffit d'en donner une fausse) ;
d'ajouter un attribut, nommé actif, dont la valeur serait de type %INTERVAL afin de préciser les auteurs censés répondre au mail pour la dernière version. Ce serait mieux que de supprimer toute mention d'un auteur devenu inactif, ou de le laisser ce qui fait croire qu'il répondra (en particulier si c'est le premier de la liste).

A propos de %INTERVAL, il faut signaler que les 2 nombres sont séparés par un « ; » et que le 2^e peut être absent. Enfin, il vaudrait mieux n'utiliser que les crochets, en utilisant la convention mathématique de les mettre à l'envers pour signifier l'exclusion.

Des DTD pour décrire et archiver les plugins

Les fichiers plugin.xml ne proposent pas de syntaxe sur les declarations de pipeline pour declarer qu'on souhaite passer apres tout le monde (l'équivalent du || dans la globale $spip_pipeline).
Peut-être faudrait-il prévoir un attribut priorite sur pour traiter cette question de façon plus générique (et moins binaire). Pour mémoire le commit qui y fait référence : http://core.spip.org/trac/spip/changeset/155b2dd691400c277e3d80d059aa910b64fe7812



Des DTD pour décrire et archiver les plugins
Attention, il est bien dit que les raccourcis SPIP peuvent être tolérés, ce qui veut dire qu'on permet gras, italique, hyperliens, listes et tableaux. Si vraiment la balise code est indispensable on peut réfléchir à un raccourci nouveau. Mais je reste sceptique sur la présence d'un tel texte ici : il s'agit de décrire les fonctionnalités du Plugin, avoir besoin de montrer du code suggère qu'il s'agit d'indications techniques sur sa mise en œuvre, c'est jouer sur les mots en n'y voyant pas une opération de configuration même si celle-ci ne se présentera pas sous la forme d'un formulaire à remplir. On peut d'ailleurs se demander si ce n'est pas le signe d'un développement inachevé.


Des DTD pour décrire et archiver les plugins
Interdire toute balise html ou raccourci SPIP sous forme de balise dans les descriptions me parait assez strict. On a besoin d'y indiquer parfois un élément de code a insérer avec la balise .

Tous les plugins n'ont pas une page de configuration sur laquelle déporter les indications de mise en oeuvre, et la doc en ligne ne suffit pas non plus à répondre au besoin. Il est utile d'avoir les indications minimales de mise en oeuvre d'un plugin dans celui-ci sans avoir besoin d'une connexion internet.
Devrait-on en revenir aux bons vieux Readme.txt, ce qui ne serait pas vraiment un progrès en terme d'interface utilisateur ?


Des DTD pour décrire et archiver les plugins
Il manque encore un spécification dans cet article, qui concerne l'installation et la désinstallation. Non seulement il faut connaître le nom du fichier contenant les fonctions chargées de cela, mais de plus il faut savoir laquelle appeler.
Actuellement, l'existence d'une fonction ${prefix_}install suffit à provoquer son appel avec comme argument install (ou uninstall si on le désactive, et aussi test qui en fait signale s'il faut appeler pour une mise à jour). Si elle n'existe pas mais que plugin.xml contient la balise version_base, on considère que ces opérations sont assurées par les fonctions ${prefix_}upgrade ${prefix_}vider_tables, leur appel étant conditionné par l'inégalité entre la valeur de version_base dans plugin.xml et sur le site.
Ces spécifications sont compatibles avec la DTD proposée, mais elles souffrent de redondances et d'incohérences dans les noms, et ne profitent pas de la fonction SPIP maj_while qui pourrait être appelée automatiquement pour les mises à jour (ce qui inclut l'installation avec le numéro 0).


Des DTD pour décrire et archiver les plugins
Je ne suis pas sûr qu'on se comprenne bien à propos du lien de configuration. Celui-ci n'a pas de rapport a priori avec la balise #CONFIGURER_META, j'en veux pour preuve que ce schéma est déjà présent dans SPIP 2.1 alors que cette version ne contient pas cette balise. Et je ne comprends pas ton argumentaire : ou bien un Plugin ne fait que « compléter une page de configuration existante » et alors il n'a pas besoin de lien de configuration, ou bien il a « une autre page de configuration » et à ce moment là je ne vois pas ce qu'on gagne à autoriser que cette page soit nommée n'importe comment.


Des DTD pour décrire et archiver les plugins
Joseph,
On en a déjà parlé, je suis tout à fait de ton avis sur les thèmes puisque je l'ai déjà exprimé ainsi dans les spécifications de développement de SVP. Cependant, je ne pense pas que ce soit nécessaire d'ouvrir un grand débat sur le sujet car c'est un mécanisme vraiment interne à SPIP.
Ce que j'imagine pour cette évolution est la chose suivante :
 Le thème, étant distribué sous forme de plugin, se doit d'avoir un préfixe unique.
 Nul n'est besoin de rejeter l'activation d'un thème si un autre est actif. On peut éventuellement pour la nouvelle version de SPIP avertir en se servant de la catégorie mais rien de plus. Ainsi, les versions précédentes de SPIP continuent à fonctionner mais sans le test.
 Si on veut distribuer tous les thèmes Z, dans un premier temps, on fait une archive themes.zip comme c'est le cas actuellement et plus tard on utilisera les collections.
Sur le sujet du lien de configuration je n'ai pas d'avis pour l'instant n'ayant pas encore utilisé la nouvelle balise d'Emmanuel mais là où je le rejoins c'est qu'aujourd'hui la configuration du plugin est gérée trop indépendamment du reste des données éventuellement créées en base par le plugin. Ce qui a pour effet, que ces données ne sont jamais nettoyées même lors d'une désinstallation du plugin.
Maintenant, pour la balise lien elle-même, je propose de la renommer doc et de s'en servir uniquement qu'à cet effet.


Des DTD pour décrire et archiver les plugins
Je crois que plusieurs personnes sont d'accord sur le fait que la situation actuelle des thèmes n'est pas pérenne à long terme. Cependant, s'il faut faire évoluer la question des thèmes concernant leur nommage, il me semble pertinent que cela se fasse en même temps que le changement de DTD pour décrire les plugins. En effet, je suppose que ce changement de DTD s'accompagnera d'une évolution de SPIP pour qu'il utilise paquet.xml préférentiellement à plugin.xml. Cette évolution du chargeur du plugin pourrait également intégrer la gestion des thèmes (par exemple en empéchant l'activation simultanée de deux thèmes en se basant non pas sur le prefix mais sur la catégorie). Dès lors, serait-il opportun d'ouvrir le débat sur spip-zone ou sur spip-dev en parallèle du travail sur la DTD ?
Concernant le lien de configuration, il faut être plus souple. En effet, un plugin n'a pas forcément sa propre page de configuration. Il peut très bien venir compléter une page de configuration existante, parce que cela est plus naturelle. Les pages de l'espace privée peuvent être complétée à l'aide de différents pipelines. Dès lors, il faut envisager de pouvoir spécifier une autre page de configuration que configurer_prefix. Dès lors, il me semblerait pertinent que l'on puisse spécifier explicitement une page de config au travers d'une balise optionnelle et, qu'à défaut, on vérifie la présence de configurer_prefix.


Des DTD pour décrire et archiver les plugins
Pour les thèmes, c'est un sujet en soi en effet. Pour ma part je ne trouve pas heureuse la règle actuelle qu'il ne peut y avoir qu'un seul thème à la fois, fondée sur l'incompatibilité dé nom.
Pour la configuration, c'est effectivement ce que tu décris. Y vois-tu un inconvénient ?
Pour ton idée que #CONFIGURER_METAS contienne la table à affecter, ce n'est pas possible parce que le compilateur de SPIP a besoin de connaître au moment de la compilation les tables SQL sur lesquelles le squelette agit : si ce n'est connu qu'au moment de l'exécution il ne peut rien faire.
L'entrée meta ici serait inutile si on décidait que tous les Plugins 

fonctionnaient comme ça, mais actuellement ils utilisent la table standard du noyau. Je ne trouve pas ça heureux parce que lorsqu'on veut faire une sauvegarde des tables SQL du Plugin on n'y trouve pas ces informations essentielles, et c'est la raison pour laquelle j'ai conçu la balise #CONFIGURER_METAS. Personnellement je trouverais normal que tous les Plugins fassent de même, mais ça ne fait pas consensus. Partant, il faut préciser dans le fichier de configuration si on utilise la table du noyau ou la table spécifique au Plugin.
J'ai complété http://www.spip-contrib.net/CONFIGU... sur ce point.
Merci de tes commentaires.


Des DTD pour décrire et archiver les plugins
Bonjour et merci pour ces précisions,
concernant les thèmes, le débat ne devrait-il pas avoir lieu sur spip-dev ou bien sur une des pages de ce site ? En effet, la question des thèmes concerne également les développeurs de thèmes et/ou de squelettes.
Concernant le lien de configuration, ce qui est proposer est une standardisation du nom de l'exec de config en configurer_prefix (que ce soit un exec en html ou php), indépendamment du système de configuration retenu.
Concernant la balise meta, je ne comprends toujours pas son usage, y compris avec la balise #CONFIGURER_METAS. Il n'en est pas fait mention dans http://www.spip-contrib.net/CONFIGU.... Si j'ai bien compris l'idée de #CONFIGURER_METAS, c'est de stocker la config d'un plugin dans une table dédiée qui est prefix_metas. Ou bien la balise meta dans paquet.xml sert-elle à spécifier dans quelle table les métas doivent être stockées ? Si oui, pourquoi le faire figurer dans paquet.xml au lieu de le faire figurer dans l'appel à #CONFIGURER_METAS ?


Des DTD pour décrire et archiver les plugins
Pour Joseph, complément à la réponse d'Eric.
En ce qui concerne le lien vers la configuration c'est expliqué dans l'article, peut-être de manière un peu sibylline, quand on parle des fichiers de nom ...exec/configurer_... dont l'existence provoque l'apparition de l'icône de configuration (clé/tournevis) dans le bloc d'administration du plugin, cet icône renvoyant vers le exec en question. C'est le même icône que celui de CFG mais celui-ci n'en avait nullement le monopole a priori.
En ce qui concerne l'entrée meta dans la DTD, c'est en rapport avec la balise #CONFIGURER_METAS.


Des DTD pour décrire et archiver les plugins
Salut Joseph,
Pour les tags, c'est prévu mais je ne l'ai pas encore implémenté dans SVP ni dans la DTD. Si on veut quelque chose d'utilisable il faudra passer de toute façon par un système d'alias comme pour la catégorie. Donc un peu de patience ça viendra.
Pour les thèmes c'est un débat que j'ai lancé, il y a quelques jours, sur spip-team et aussi dans l'article SVP, impacts sur l'environnement du plugin, car au delà de ce que tu rapportes ça me pose un vrai problème d'affichage et de modélisation dans SVP : tous les thèmes sont vus comme des paquets d'un même plugin, le plugin « theme ». En soit ça pourrait être envisageable mais je ne suis pas persuadé que ce soit la panacée. Donc oui, la réflexion est en cours.
Par contre, pour les squelettes non je ne crois pas que ce soit une bonne idée.
Pour le lien, il doit être utilisé que pour la documentation du plugin, le bouton de configuration est un souvenir du passé, ou doit le devenir. Peut-être que le nom « doc » serait plus approprié.


Des DTD pour décrire et archiver les plugins
Qu'en est-il des « tags » ou « mots-clés » optionnels permettant de catégoriser plus finement le plugin (avec le problème de la traduction de ses tags) ?
Quitte à revoir la DTD des plugins, ne faudrait-il pas également prendre en compte le cas des thèmes ? Actuellement ils ont tous le même préfixe, ce qui pose un problème pour distinguer deux thèmes ou pour mettre à jour un thème. Dans la mesure où tous les thèmes ont la même catégorie, pourrait-on envisager qu'ils aient chacun leur propre préfixe, l'interface de gestion des plugins se chargeant de ne permettre l'activation que d'un seul thème à la fois. Dans la foulée, ZenGarden pourrait évoluer pour prendre en compte les thèmes présents dans le répertoire plugins (identifier par leur catégorie) sans nécessiter de les placer dans un sous-repertoire themes. Ainsi, la mise à jour des thèmes pourra être gérée avec STEP.
On peut se demander s'il ne faut pas prévoir un mécanisme analogue pour les squelettes : ne pas permettre d'installer deux squelettes en même temps. Mais ce point est plus délicat car certains squelettes fonctionnent par surcharge d'un premier squelette (notamment avec Z). Du coups, soit ces squelettes surchargeant ne devraient pas être dans la catégorie squelette (ce qui serait bizarre ou alors en faisant évoluer cette catégorie avec des squelettes de base et des extensions de squelettes) ou se baser sur un système de tags ou autre chose. Bref, on peut poser la question mais c'est beaucoup moins évident pour les squelettes.
Que représente l'attribut 'meta' dans la balise paquet ?
Qu'en est-il du lien pour configurer le plugin ? Les discussions n'avaient-elles pas porté à un moment sur la possibilité d'indiquer la page de configuration du plugin, indépendamment du système de configuration utilisé ?
Bien cordialement


Des DTD pour décrire et archiver les plugins
C'est sûrement une bonne chose d'avoir des DTD pour décrire formellement le format des fichiers de plugins. Cependant, pour les humains qui liront l'article, est-ce qu'il serait possible de mettre aussi des exemples ?
Félicitations pour le boulot accompli jusque là.