Pour la version 3.0 nous avons au travers du paquet.xml continué à normaliser la structure des plugins et des fichiers qui les composent.
Je pense qu’il serait pas inintéressant de continuer dans cette voie, ce qui pourrait aussi permettre d’aller plus dans la génération automatique avec La Fabrique.
En plus des fichiers actuels (administrations, options, fonctions…) je proposerais bien de normaliser à la racine du plugin les fichiers suivants :
${prefixe}_logo.png pour désigner le logo du plugin. En effet, on a tendance depuis SPIP 3 à ranger ce fichier dans prive/themes/spip/images/ ce qui n’a pas vraiment de sens car le logo n’est pas surchargeable. Peut-être faudrait-il aussi le décliner en 2 formats, 64 et 32.
${prefixe}_configurations.php pour y inclure les déclarations liées à la base de données ainsi que celles liées aux metas de configuration (cf aussi avec la proposition d’amélioration de la gestion de la config).
${prefixe}_autorisations.php pour y inclure les autorisations spécifiques.
${prefixe}_pipelines.php pour y inclure les pipelines spécifiques autres que ceux déjà dans les autres fichiers normalisés.
Pour la version 3.0 nous avons au travers du paquet.xml continué à
normaliser la structure des plugins et des fichiers qui les composent.
Je pense qu'il serait pas inintéressant de continuer dans cette voie, ce
[...]
Un avis ?
Bien, si l'un n'empêche pas l'autre (ie que la déclaration dans paquet.xml continue de fonctionner) je ne vois pas d'inconvénients.
Par contre le nom «configurations» pour déclarer les tables, je trouve pas ça top. Même si est ajouté dedans des choses concernant effectivement les variables de configurations. Peut être «declarations» ?
J'ai vu aussi que Cédric parfois essayait de regrouper des fichiers pour éviter (je suppose) l'ouverture en lecture de nombreux fichiers. Ça me semble à la fois louable, et à la fois moins clair dans les séparations pour le développeur/bidouilleur. Je sais pas si c'est possible d'arriver à un compromis de tout ça.
Ensuite, l'argument «Fabrique» me semble un peu fallacieux ^^. Sur ces propositions, je vois pas trop ce que ça changerait — pour le moment — pour elle.
Pour la version 3.0 nous avons au travers du paquet.xml continué à
normaliser la structure des plugins et des fichiers qui les composent.
Je pense qu'il serait pas inintéressant de continuer dans cette voie, ce
qui pourrait aussi permettre d'aller plus dans la génération automatique
avec La Fabrique.
et aussi de simplifier la vie des devs de plugins débutants.
- ${prefixe}_configurations.php pour y inclure les déclarations liées à la
base de données ainsi que celles liées aux metas de configuration (cf aussi
avec la proposition d'amélioration de la gestion de la config).
je plussois à la remarque de Matthieu: ${prefixe}_declarations.php me semble plus compréhensible / adapté
Un avis ?
pour ${prefixe}_logo.png, ${prefixe}_autorisations.php et ${prefixe}_pipelines.php : 100% pour
je plussois à la remarque de Matthieu: ${prefixe}_declarations.php me
semble plus compréhensible / adapté
+1
Un avis ?
pour ${prefixe}_logo.png, ${prefixe}_autorisations.php et
${prefixe}_pipelines.php : 100% pour
Tout pareil
Gaffe : en morcelant en trop de fichiers, on oblige a faire plein de fichiers sur des petits plugins et c'est une penalité en perf, obligeant a charger 3 ou 4 fichiers la ou un seul suffisait.
Peut-être faudrait-il aussi le décliner en 2 formats, 64 et 32.
Pour les déclinaisons je ne pense pas que ça soit nécessaire, autant fixer la taille à la plus grande qu'on utilise en génral et zou (128 ou 64 ?)
Achtung la aussi : si on mets systématiquement des logos plus grand que 32px, l'affichage de la page plugin oblige la première fois a faire plein de réductions d'images, et ça peut faire un timeout, ce qui est pas du tout rassurant.
Dans ce cas il faut prévoir la possibilité de mette une version 32px a cote, et faire en sorte qu'elle soit prise par spip plutôt que grosse image+réduction.
Gaffe : en morcelant en trop de fichiers, on oblige a faire plein de fichiers sur des petits plugins et c'est une penalité en perf, obligeant a charger 3 ou 4 fichiers la ou un seul suffisait.
Tout va bien vu qu'on oblige pas Eric et Matthieu précisent bien qu'on peut toujours faire des déclarations manuelles dans le paquet.xml
Achtung la aussi : si on mets systématiquement des logos plus grand que 32px, l'affichage de la page plugin oblige la première fois a faire plein de réductions d'images, et ça peut faire un timeout, ce qui est pas du tout rassurant.
Dans ce cas il faut prévoir la possibilité de mette une version 32px a cote, et faire en sorte qu'elle soit prise par spip plutôt que grosse image+réduction.
Ha ok, dans ce cas il nous faut au moins logo_32 et logo_128/64.
Ha ok, dans ce cas il nous faut au moins logo_32 et logo_128/64.
Certains plugins ont une déclinaison juste en 32 pixels (dont plusieurs
plugins de la dist comme breves). Si l'on doit imposer/recommander une
taille en particulier, il me semble que c'est bien en 32 pixels, 128 ou 64
n'étant alors qu'optionnels.
Je comprends bien qu'il ait plusieurs besoins. La question est de savoir
qu'est le *minimum requis*.
Or, il est plus facile de réduire que d'agrandir un logo. Et quand on
dispose que d'un visuel en 32px, cela signifie-t-il qu'il faudra à l'avenir
générer obligatoirement une version 64 ou 128 pour déposer un plugin ?
Je comprends bien. Le problème est souvent de créer cette version de 64
pixels, surtout quand on n'est pas graphiste et que les bibliothèques
utilisées fournissent du 32 max.
En fait, on en revient à la question de la librairie fatcow, utilisée
souvent pour l'interface privée et dont les icônes sont également utilisées
comme icône de plugin, sachant que les icônes fatcow sont disponibles en 32
pixels max.
